Lower suppressed vocabulary failures below error level

[dahlia]

Summary

Generated vocabulary accessors log parsing and fetch failures at error level even when callers pass suppressError: true. This turns expected rejection of malformed remote objects into application error-tracking events despite the accessor returning null as requested.

Observed behavior

In @fedify/vocab-tools/src/property.ts, both the document-loader catch and JSON-LD parsing catch call getLogger(["fedify", "vocab"]).error(...) when options.suppressError is enabled, then return null.

Hackers' Pub calls Announce.getObject({ suppressError: true }) for untrusted inbox input. A remote URL returned a document that was not an ActivityStreams Object, so the accessor correctly returned null, but its error log produced five Sentry events under GRAPHQL-42 with TypeError: Expected an object of any type of: https://www.w3.org/ns/activitystreams#Object.

Expected behavior

Failures intentionally absorbed by suppressError: true should be logged below error level, probably warning or debug. Callers that omit suppressError would continue to receive the thrown exception, so genuinely unhandled failures would remain visible to error tracking.

Production evidence

The affected Sentry issue is https://hackerspub.sentry.io/issues/GRAPHQL-42.

[dahlia]

I think lowering these suppressed failures to warning level would be appropriate. They are still worth surfacing for diagnostics, but should not be treated as application errors when the caller explicitly opted into suppressError: true.

[A-S-Manoj]

Hi @dahlia, are you actively working on this, or can I take it? Would be my first contribution to fedify — happy to open a PR.

[dahlia]

@A-S-Manoj Sorry, it's reserved for OSSCA 2026 mentees.

[A-S-Manoj]

Got it, thanks for letting me know! I'll look for another open issue to contribute to. Good luck to the mentees!