WebSocket returns data that doesn't exist in database (CLI works fine)
🪲Bug Report
1. Full-scope summary
Problem: The frontend gets prayer data over the Convex WebSocket that does not exist in the database (and sometimes the returned document _id is from another table, e.g. notificationSettings). The same Convex deployment returns correct data when queried via the CLI (e.g. empty array when no prayer exists). So we have a WebSocket vs CLI data mismatch for the same deployment and same logical query.
Key details:
Code: A mutation queries prayers by language and date and returns the first result (or null). Via WebSocket it returns a document; via CLI it returns []/null when no prayer exists.
Schema: Table prayers with index by_language_and_date on language and date. The phantom document’s _id is from table notificationSettings, not prayers.
Observed: Same wrong result with queries, actions, and mutations over WebSocket; different browsers/devices; cache cleared; redeployed. CLI is always correct.
2. Version & environment
Detail Value
Convex version 1.31.5
Convex client version 1.31.5 (convex npm package)
Programming language TypeScript
Runtime (with version) Node v24.13.0
(Framework: Next.js 16.1.3, React 19.2.3)
3. Reproducible scenario (bug)
Steps:
CLI – correct behaviour
Run:
npx convex run "prayers:debugListAllPrayers" '{"date": "2026-02-01", "language": "en"}'
Result: [] (no prayer exists for that date/language).
WebSocket – wrong behaviour
In the app, open the page that calls getPrayerViaMutation with the same date and language.
Result: Frontend receives a prayer object (e.g. title "In the Stillness of Winter's Heart") with an _id and full JSON, as if a prayer existed.
Proof the WebSocket data is wrong
Use the returned _id in a delete (or any) operation that expects a prayers document.
Result: ArgumentValidationError: Found ID "..." from table \notificationSettings
Minimal code (mutation that shows the mismatch):
export const getPrayerViaMutation = mutation({
args: {
language: v.union(v.literal("en"), v.literal("es"), v.literal("fr"), v.literal("pt")),
date: v.string(),
},
handler: async (ctx, args) => {
const prayer = await ctx.db
.query("prayers")
.withIndex("by_language_and_date", (q) =>
q.eq("language", args.language).eq("date", args.date)
)
.order("desc")
.first();
return prayer;
},
});
Same mutation: correct result via CLI, wrong (phantom/cross-table) result via WebSocket.
4. Network test
(Ran against my DEV deployment; same Convex infrastructure. All checks passed.)
- Performing network test...
Deployment URL: [REDACTED - per forum guidelines]
OK: DNS lookup => 52.44.230.118:ipv4 (86.96ms)
OK: TCP connect (24.51ms)
OK: TCP connect (21.98ms)
OK: HTTP check (35.73ms)
OK: HTTPS check (60.43ms)
OK: WebSocket connection established.
OK: echo 128 B (16.98ms, 7.4 KB/s)
OK: echo 4.0 MB (711.45ms, 5.6 MB/s)
Network test passed.
5. What I’d like
WebSocket responses should match CLI for the same deployment and same function: return the actual document from the database or null when none exists, and never return a document from a different table.
Account verified – you can check my deployment logs if needed.
Thanks in advance for your help!
Problem: The frontend gets prayer data over the Convex WebSocket that does not exist in the database (and sometimes the returned document _id is from another table, e.g. notificationSettings). The same Convex deployment returns correct data when queried via the CLI (e.g. empty array when no prayer exists). So we have a WebSocket vs CLI data mismatch for the same deployment and same logical query.
Key details:
Code: A mutation queries prayers by language and date and returns the first result (or null). Via WebSocket it returns a document; via CLI it returns []/null when no prayer exists.
Schema: Table prayers with index by_language_and_date on language and date. The phantom document’s _id is from table notificationSettings, not prayers.
Observed: Same wrong result with queries, actions, and mutations over WebSocket; different browsers/devices; cache cleared; redeployed. CLI is always correct.
2. Version & environment
Detail Value
Convex version 1.31.5
Convex client version 1.31.5 (convex npm package)
Programming language TypeScript
Runtime (with version) Node v24.13.0
(Framework: Next.js 16.1.3, React 19.2.3)
3. Reproducible scenario (bug)
Steps:
CLI – correct behaviour
Run:
npx convex run "prayers:debugListAllPrayers" '{"date": "2026-02-01", "language": "en"}'
Result: [] (no prayer exists for that date/language).
WebSocket – wrong behaviour
In the app, open the page that calls getPrayerViaMutation with the same date and language.
Result: Frontend receives a prayer object (e.g. title "In the Stillness of Winter's Heart") with an _id and full JSON, as if a prayer existed.
Proof the WebSocket data is wrong
Use the returned _id in a delete (or any) operation that expects a prayers document.
Result: ArgumentValidationError: Found ID "..." from table \notificationSettings
, which does not match the table name in validator . So the WebSocket is returning a document from another table, not fromprayersMinimal code (mutation that shows the mismatch):
export const getPrayerViaMutation = mutation({
args: {
language: v.union(v.literal("en"), v.literal("es"), v.literal("fr"), v.literal("pt")),
date: v.string(),
},
handler: async (ctx, args) => {
const prayer = await ctx.db
.query("prayers")
.withIndex("by_language_and_date", (q) =>
q.eq("language", args.language).eq("date", args.date)
)
.order("desc")
.first();
return prayer;
},
});
Same mutation: correct result via CLI, wrong (phantom/cross-table) result via WebSocket.
4. Network test
(Ran against my DEV deployment; same Convex infrastructure. All checks passed.)
- Performing network test...
Deployment URL: [REDACTED - per forum guidelines] OK: DNS lookup => 52.44.230.118:ipv4 (86.96ms) OK: TCP connect (24.51ms) OK: TCP connect (21.98ms) OK: HTTP check (35.73ms) OK: HTTPS check (60.43ms) OK: WebSocket connection established. OK: echo 128 B (16.98ms, 7.4 KB/s) OK: echo 4.0 MB (711.45ms, 5.6 MB/s) Network test passed.5. What I’d like
WebSocket responses should match CLI for the same deployment and same function: return the actual document from the database or null when none exists, and never return a document from a different table.
Account verified – you can check my deployment logs if needed.
Thanks in advance for your help!
Join the Convex Discord! Explore Convex, the backend platform that keeps your app in sync.
15,138Members
Resources
Recent Announcements
Similar Threads
Was this page helpful?
