fix(photon): handle inbound richlinks and fall back on outbound enable_data_detection errors - #54406
Closed
cacheburner-agent wants to merge 3 commits into
Conversation
…malizeContent
When someone sends a link via iMessage, Apple's client renders it as a
rich link balloon (com.apple.messages.URLBalloonProvider). spectrum-ts
inbound mapper converts this to a 'richlink' content object with the URL
in content.url. However, the sidecar's normalizeContent did not handle
the 'richlink' type — it fell through to the generic fallback which
returned { type: "richlink" } without the URL, causing the Python
adapter to receive an empty/unknown message.
Fix by adding a 'richlink' case to normalizeContent that extracts the
URL as plain text, so the inbound message arrives as a regular text
message containing the link.
…nable_data_detection spectrum-ts enables enable_data_detection when outbound text contains links, triggering Apple's link-preview pipeline. Apple's IMAgentKit send path rejects this field with a ValidationError, silently dropping the message. Fix by catching the error in the /send handler and retrying with protocol prefixes (http://, https://) stripped. Without a protocol prefix, spectrum-ts's markdown link detector does not fire, data detection stays off, and the message delivers. iOS still renders domain-like text as a tappable link on the receiving end. When the error is unrelated to data detection, the original error is re-thrown so existing error handling paths work unchanged.
…a-detection fallback Adds two static assertion tests matching the existing pattern in test_spectrum_patch.py: - test_sidecar_normalize_content_handles_richlink: verifies the sidecar's normalizeContent handles the 'richlink' content type and extracts the URL - test_sidecar_send_falls_back_on_enable_data_detection_error: verifies the /send handler catches enable_data_detection errors and retries with protocol prefixes stripped
alt-glitch
added
type/bug
Author
|
Closing because this is already fixed, see the linked issue: #54402 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two separate bugs in the Photon sidecar related to iMessage rich links — one inbound, one outbound.
Bug 1 (inbound): When someone sends a link via iMessage, Apple renders it as a rich link balloon. spectrum-ts converts this to a
richlinkcontent object with the URL incontent.url, but the sidecar'snormalizeContent()didn't handle this type — it fell through to the generic fallback, dropping the URL. The Python adapter received an empty message.Fix: Added a
richlinkcase tonormalizeContent()that extracts the URL as plain text.Bug 2 (outbound): When Hermes sends a message containing a URL with a protocol prefix, spectrum-ts sets
enable_data_detection: trueon the gRPC payload. Apple's IMAgentKit rejects this field with aValidationError, silently dropping the message with HTTP 500.Fix: Wrapped
space.send()in a try/catch in the/sendhandler. When the error message containsenable_data_detection, the text is retried with protocol prefixes stripped. Without a protocol prefix, spectrum-ts's link detector doesn't fire, data detection stays off, and the message delivers. iOS still renders domain-like text as a tappable link on the receiving end. Non-data-detection errors are re-thrown unchanged.An alternative approach for Bug 2 would be patching spectrum-ts's
dataDetectionOptionfunction at postinstall time (via the existingpatch-spectrum-mixed-attachments.mjsinfrastructure) to always return{}. That would be more aggressive — it disables data detection for all messages, not just on failure. The fallback approach in this PR is less invasive: it preserves data detection when it works and only strips it when Apple rejects the message.Closes #54402
Test Plan
https://example.com) to Hermes via iMessage — inbound message should contain the URL as texthttps://example.com) via iMessage — message should deliver successfully