Summary
The BlueBubbles server's /api/v1/message text endpoint throws undefined is not an object (evaluating 'guid.startsWith') when the message text contains certain double-underscore patterns (e.g. an identifier-shaped token with __ separators). Short messages and messages without the pattern send successfully.
Repro
- POST
/api/v1/message/text with a body whose message field contains a literal identifier of the shape prefix__middle__suffix (two underscores around the middle segment).
- Server returns error:
undefined is not an object (evaluating 'guid.startsWith').
- Same body with single-underscore (
prefix_middle_suffix) sends successfully.
Expected
Message sends as plain text — double underscores have no special meaning in iMessage and should be treated as literal characters in the message body.
Actual
Error is thrown server-side; the message is dropped silently from the user's perspective (no delivery, no client-side error indication beyond the API response).
Workaround
On the client side, replace __ with _ or another separator (e.g. /) in outgoing text before sending.
Likely cause
The text appears to be parsed as if it contained an identifier or reference pattern; a downstream code path then dereferences a guid that comes back undefined when the pattern doesn't resolve to a real object. The guid.startsWith call site is the symptom — the upstream parse/lookup is the bug.
Environment
- BlueBubbles server: latest (please confirm by version checked at the time of triage)
- macOS host: 26.2 (build 25C56)
- Client: REST API consumer over HTTP
Happy to provide a more precise server version on request — wanted to file the repro while it was fresh.
Summary
The BlueBubbles server's
/api/v1/messagetext endpoint throwsundefined is not an object (evaluating 'guid.startsWith')when the message text contains certain double-underscore patterns (e.g. an identifier-shaped token with__separators). Short messages and messages without the pattern send successfully.Repro
/api/v1/message/textwith a body whosemessagefield contains a literal identifier of the shapeprefix__middle__suffix(two underscores around the middle segment).undefined is not an object (evaluating 'guid.startsWith').prefix_middle_suffix) sends successfully.Expected
Message sends as plain text — double underscores have no special meaning in iMessage and should be treated as literal characters in the message body.
Actual
Error is thrown server-side; the message is dropped silently from the user's perspective (no delivery, no client-side error indication beyond the API response).
Workaround
On the client side, replace
__with_or another separator (e.g./) in outgoing text before sending.Likely cause
The text appears to be parsed as if it contained an identifier or reference pattern; a downstream code path then dereferences a
guidthat comes backundefinedwhen the pattern doesn't resolve to a real object. Theguid.startsWithcall site is the symptom — the upstream parse/lookup is the bug.Environment
Happy to provide a more precise server version on request — wanted to file the repro while it was fresh.