Per discussion in #34, we shouldn't JSON.parsedelete events' payload because it's a stringy ID and needs to remain a string to avoid exceeding float precision issues.
This appears to be the only event for which this is the case, per Mastodon docs (no other events mention string ID). Therefore, this PR proposes a simple solution: skip JSON.parseing the event payload if it's a delete.
With this in place, the following streaming data chunk:
event: delete\ndata: 110988741790818968\n\n
is parsed into { event: 'delete', data: '110988741790818968' } as expected (and not parseInt('110988741790818968') which is 110988741790818980…). All other events are processed as before.
Per discussion in #34, we shouldn't
JSON.parsedeleteevents' payload because it's a stringy ID and needs to remain a string to avoid exceeding float precision issues.This appears to be the only event for which this is the case, per Mastodon docs (no other events mention
string ID). Therefore, this PR proposes a simple solution: skipJSON.parseing the event payload if it's a delete.With this in place, the following streaming data chunk:
is parsed into
{ event: 'delete', data: '110988741790818968' }as expected (and notparseInt('110988741790818968')which is 110988741790818980…). All other events are processed as before.