Skip to content

Conversation

rhcarvalho
Copy link
Contributor

Based on the fact that Phoenix Channels use a JSON-based serializer 1, assume the error reason is a JSON-serializable object.

Without this step, we get JavaScript's native string representation of the value, which leads to unhelpful error messages such as:

failed with reason: [object Object]

instead of

failed with reason: {"reason":"unmatched topic"}

  • This is an improvement over Ensure Promise rejections include stack traces #3738
  • Maybe long-term we might consider custom errors to be easier to match / group in error monitoring tools like Sentry? For now I'm satisfied with keeping LV's implementation as simple as possible.

Based on the fact that Phoenix Channels use a JSON-based serializer [1],
assume the error reason is a JSON-serializable object.

Without this step, we get JavaScript's native string representation of
the value, which leads to unhelpful error messages such as:

  failed with reason: [object Object]

instead of

  failed with reason: {"reason":"unmatched topic"}

[1]: https://hexdocs.pm/phoenix/1.8.1/writing_a_channels_client.html#message-format
@rhcarvalho rhcarvalho force-pushed the pr-json-encoded-error-reason branch from 3f0a873 to 499b350 Compare September 16, 2025 10:10
@rhcarvalho
Copy link
Contributor Author

Rebased against latest main branch and ran npm run js:format, which split a line into two :)

I've been running this patch in production for ~2 weeks and have not seen any case of unserializable data attempting to go into the error message.

It has had the benefit of going from failed with reason: [object Object] to failed with reason: {"reason":"unmatched topic"} (which seem to happen frequently when the LongPoll transport is used, haven't figure out if there's a fix for that, but that's off-topic :) )

@SteffenDE SteffenDE merged commit e9c784a into phoenixframework:main Sep 16, 2025
7 checks passed
@SteffenDE
Copy link
Collaborator

Yeah, I think it's good :)

@rhcarvalho rhcarvalho deleted the pr-json-encoded-error-reason branch September 16, 2025 14:29
SteffenDE pushed a commit that referenced this pull request Sep 18, 2025
Based on the fact that Phoenix Channels use a JSON-based serializer [1],
assume the error reason is a JSON-serializable object.

Without this step, we get JavaScript's native string representation of
the value, which leads to unhelpful error messages such as:

  failed with reason: [object Object]

instead of

  failed with reason: {"reason":"unmatched topic"}

[1]: https://hexdocs.pm/phoenix/1.8.1/writing_a_channels_client.html#message-format
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants