Recording shard upload logs a network failure as 'server refused the shard'
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- backend, observability
Research direction
Start by tracing the RealtimeSession recording shard upload and retry logging, using the reported Failed to fetch request failure and the server refused the shard retry message as entry points. Keep transport failures distinguishable from server rejections in the logs; done when the network outage is reported as a network failure while retry and local storage behavior remain intact.
Written by the indexing model from the issue text.
Description
Describe the bug
When a recording shard upload fails because the network is down, the console reports server refused the shard. The request never reached the server.
Found by: the Caliber smoke run of the MJ next fixes waiting for 6.2.x (bizapps-caliber smoke/MJ-NEXT-6.2-SMOKE.md, branch smoke/mj-next-6.2). Host: MJ origin/next bf09290c4c + PR #6005, SQL Server, Caliber widget in headless Chromium driven by smoke/mj-next/live-driver.mjs (fake microphone), 2026-10-22.
How it was found
S5.1 / S5.3: the driver cuts the network with CDP Network.emulateNetworkConditions {offline:true} mid-call. Each failed upload logs:
[RealtimeSession] Recording shard <session>/3 request failed: Failed to fetch TypeError: Failed to fetch
[RealtimeSession] Recording shard 3 upload failed (attempt 1/3: server refused the shard); will retry next flush: server refused the shard
...
[RealtimeSession] Dropping recording shard 2 from the retry queue after 3/3 failed uploads (server refused the shard); it stays in the local store ...
Expected behavior
A transport failure is logged as a network failure, kept distinct from a server rejection (4xx, conflict).
Impact
Low, wording only. The behavior is correct: retry, then the local store, then re-send. With a 25 s outage, all 8 queued shards uploaded within 40 ms of reconnect, and the recording had no gaps. But support chasing a candidate's lost audio would look for a server-side rejection that never happened.
Relates to: PR #5246 (#5197).
- Dominant language
- TSQL
- Stars
- 32
- Forks
- 7
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 714
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MemberJunction/MJ
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MemberJunction/MJ#6024 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MemberJunction/MJ#6018 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
MemberJunction/MJ#5952 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
MemberJunction/MJ#5930 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
MemberJunction/MJ#5864 ·
Maintainers usually reply within 1 day
All issues in MemberJunction/MJ
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
AstrBotDevs/AstrBot#10720 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Maintainers usually reply within 1 day
-
bug: author create/update with an unknown avatarId returns 404 instead of 400 UNKNOWN_REFERENCEPossibly taken @Vinu2111 claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
atomityhq/blog-cms#59 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
area: core
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day