`fedify lookup` fails to properly handle network errors during object resolution

[dahlia]

Summary

The fedify lookup command does not properly handle certain network-related errors during ActivityPub object resolution, resulting in cryptic “could not parse an IP from hosts file” error messages instead of meaningful error reporting. This prevents users from understanding what went wrong and makes debugging difficult.

Expected Behavior

When network issues occur during object lookup, the command should:

1. Provide clear, descriptive error messages explaining what failed
2. Gracefully handle network errors without exposing internal parsing errors
3. Either retry appropriately or fail with a user-friendly message
4. Complete the operation without hanging or producing confusing output

Actual Behavior

When certain network conditions trigger errors, the command displays:

* Looking up the object...could not parse an IP from hosts file
could not parse an IP from hosts file
* Looking up the object...

The error message is unclear and doesn't help users understand:

• What specific network operation failed
• Whether this is a temporary or permanent issue
• What steps they can take to resolve the problem

Environment

• OS: macOS
• Runtime: Deno
• Runtime version: Unknown
• Fedify CLI version: 1.1.1

Logs / Screenshots

Steps to Reproduce

1. Run: fedify lookup -ad [email protected]
2. Observe the unhelpful error messages when network issues occur
3. Note that the command fails to provide actionable error information

[!NOTE] This issue appears to manifest under certain network conditions and may be more easily reproduced in specific geographical regions or network configurations.

Suggested Solution

@ThisIsMissEm suggested that this might need to be an allSettled or have a .catch handler, indicating that the issue could be related to unhandled promise rejections or inadequate error handling in asynchronous operations during the lookup process.

The fix should likely involve:

• Adding proper error handling around network operations
• Using Promise.allSettled() for concurrent operations that might fail
• Adding .catch() handlers to prevent unhandled rejections
• Providing user-friendly error messages that explain what failed and why

Additional Notes

• Originally reported by @ThisIsMissEm via Discord
• The -a flag enables authorized fetch
• The -d flag enables debug output
• The underlying network operations may be succeeding or failing, but the error handling logic is not properly managing the failure cases
• This affects user experience and makes debugging ActivityPub connectivity issues much more difficult

[ThisIsMissEm]

Keep in mind I cannot reproduce in 1.8.5

[dahlia]

I think we should still try to artificially reproduce similar network conditions to test the error handling robustness. The original error message “could not parse an IP from hosts file” suggests this might be related to DNS resolution issues.

Here are some methods we could try to simulate the problematic network conditions:

• DNS-related testing:

  # Temporarily modify hosts file to cause DNS resolution conflicts
  echo "127.0.0.1 activitypub.blog" >> /etc/hosts
  fedify lookup -ad [email protected]
  # Remember to remove the entry afterwards
  

• Network connectivity testing:

  # Block connections to specific hosts (Linux)
  sudo iptables -A OUTPUT -d activitypub.blog -j DROP
  fedify lookup -ad [email protected]
  

If the current error handling gracefully shows meaningful error messages in these scenarios, then the bug has likely been fixed. If we still get cryptic messages like “could not parse an IP from hosts file”, then there's still room for improvement in the error handling logic.

This would help us verify whether the underlying error handling robustness has actually been improved, or if the fix was just coincidental to the specific network conditions that were originally encountered.

[ellemedit]

I'll look this next weekend if no one takes

[ellemedit]

poisoning DNS with conflict doesn't work to reproduce abvoe. it results:

JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 Task cli deno task -f @fedify/cli run "lookup" "@[email protected]" JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 Task codegen (@fedify/cli) deno task -f @fedify/fedify codegen JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 Task codegen (@fedify/fedify) GENPATH=vocab-$(deno eval "console.log(crypto.randomUUID());").ts && deno run --allow-read --allow-write --check src/codegen/main.ts src/vocab/ src/vocab/$GENPATH && deno fmt src/vocab/$GENPATH && mv src/vocab/$GENPATH src/vocab/vocab.ts && deno cache src/vocab/vocab.ts && deno check src/vocab/vocab.ts JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 /Users/mars/dev/fedify/packages/fedify/src/vocab/vocab-adfd611a-f77e-41eb-91fa-ba9d8b9a3152.ts Checked 1 file JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 ╭ Warning │ │ Ignored build scripts for packages: │ npm:[email protected] │ npm:[email protected] │ npm:[email protected] │ │ Lifecycle scripts are only supported when using a node_modules directory. │ Enable it in your deno config file: │ "nodeModulesDir": "auto" ╰─ JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 Task run (@fedify/cli) deno run --allow-all src/mod.ts "lookup" "@[email protected]" JSR specifiers are not yet supported in package.json: @std/dotenv@^0.225.5 JSR specifiers are not yet supported in package.json: @std/assert@^0.226.0 JSR specifiers are not yet supported in package.json: @std/[email protected] JSR specifiers are not yet supported in package.json: @std/yaml@^1.0.6 ⠋ Looking up the object...(node:72766) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead. ✖ Failed to fetch @[email protected] Error: It may be a private object. Try with -a/--authorized-fetch.

So I guess we need to find another way to reproduce it. I didn't try second one.