$ nc -C tarta.nabijaczleweli.xyz 12122
GET /streaming?_t=1752534314122 HTTP/1.1
Host: tarta.nabijaczleweli.xyz:12122
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:142.0) Gecko/20100101 Firefox/142.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: AAAAAAAAAAAAAAAAAAAAAA==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
the parameters almost don't matter so long as the server
replies with an upgrade, then press enter once or twice,
at which point the server will have crashed after
INFO 1 [core nest] NestFactory: Starting Nest application...
ERR * [core] Uncaught exception (uncaughtException): RangeError: Invalid WebSocket frame: invalid opcode 13
at Receiver.getInfo (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:311:26)
at Receiver.startLoop (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:155:16)
at Receiver._write (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:94:10)
at writeOrBuffer (node:internal/streams/writable:572:12)
at _write (node:internal/streams/writable:501:10)
at Writable.write (node:internal/streams/writable:510:10)
at Socket.socketOnData (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/websocket.js:1355:35)
at Socket.emit (node:events:518:28)
at addChunk (node:internal/streams/readable:561:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
at Readable.push (node:internal/streams/readable:392:5)
at TCP.onStreamRead (node:internal/stream_base_commons:189:23) {
code: 'WS_ERR_INVALID_OPCODE',
[Symbol(status-code)]: 1002
}
INFO * [core] The process is going to exit with code 1
node:events:496
throw er; // Unhandled 'error' event
^
RangeError: Invalid WebSocket frame: invalid opcode 13
at Receiver.getInfo (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:311:26)
at Receiver.startLoop (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:155:16)
at Receiver._write (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/receiver.js:94:10)
at writeOrBuffer (node:internal/streams/writable:572:12)
at _write (node:internal/streams/writable:501:10)
at Writable.write (node:internal/streams/writable:510:10)
at Socket.socketOnData (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/websocket.js:1355:35)
at Socket.emit (node:events:518:28)
at addChunk (node:internal/streams/readable:561:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:512:3)
at Readable.push (node:internal/streams/readable:392:5)
at TCP.onStreamRead (node:internal/stream_base_commons:189:23)
Emitted 'error' event on WebSocket instance at:
at Receiver.receiverOnError (/srv/Sharkey/node_modules/.pnpm/ws@8.18.1_bufferutil@4.0.9_utf-8-validate@6.0.5/node_modules/ws/lib/websocket.js:1199:15)
at Receiver.emit (node:events:518:28)
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
code: 'WS_ERR_INVALID_OPCODE',
[Symbol(status-code)]: 1002
}
Node.js v22.14.0
ELIFECYCLE Command failed with exit code 1.
This works through some reverse proxies (HAProxy, Caddy),
but not through others (Cloudflare, nginx, Apache(?))
Instead, just hang up if the client violates protocol
Fixes https://101010.pl/@nabijaczleweli/114854334401159070
Misskey's code does the same, but our groups behave differently enough
that this may be not the best choice
for example, let's say we have:
- notifications 1-5 for reaction to note A
- notifications 6-8 for reaction to note B
- notifications 9-12 for reaction to note A
- notification 13-19 for non-groupable events
- notification 20 for reaction to note A
and that events happened one every minute (so the last notification is
from 20 minutes ago)
client requests the most recent 10 notifications; we fetch
notifications 1-10, and reply:
- grouped id 6 for reactions 6-8 to note B
- grouped id 10 for reactions 1-5, 9-10 to note A
then the client requests 10 more notifications, untilId=10; we fetch
notifications 11-20, and reply:
- non-grouped notifications 13-19
- grouped id 20 for reactions 11,12,20 to note A
because we sort by id, and also the `createdAt` marks the _newest_
event in each group, the client will then show:
6 reactions to note B, 6 minutes ago
4 reactions to note A, 1 minute ago
notifications 13-19, 13 minutes to 19 minutes ago
3 reactions to note A, 11 minutes ago
I don't know how to make this work better ☹
this will make it much easier to debug problems for instances that run
unreleased versions!
when run on a tagged commit, `git describe --tags` prints the tag name;
otherwise it prints something like `2025.4.3-32-ga4c0ef824c` which
means:
- the closest tag is 2025.4.3
- there are 32 commits between that tag and this commit
- this commit's id is `a4c0ef824c` (the `g` is just a prefix)
notice that the version as reported by the frontend (in
`/about-sharkey` for example) is _not_ changed, that one is still
sourced from `/package.json` (so, for example, you don't get a
"sharkey has been updated!" pop-up every time)
the top element must be a single <a> in order for verification to work, so MfmService has gained an 'inline' argument to remove the <p> added by default
