Symptom
UpstashTransport reports a successful flush when Redis rejects LPUSH inside an HTTP 200 pipeline. The batch is already gone from logBuffer, so the records are lost. The linked issue does not give a user-facing error string.
Evidence what you'll see
- The mocked pipeline body is
[{ error: 'WRONGTYPE Operation against a key holding the wrong kind of value' }, { error }]. After_flush(),logBuffer.lengthis0and there is no thrown error. - Upstash's pipeline format returns one result or error object per command. Checking only
response.okdoes not establish that the logs were written. - The final destroy callback also reports success for these rejected writes.
Why it happens
The transport treated every HTTP-successful pipeline as a successful write. Pull request 27480 fails the flush when LPUSH is rejected, puts the batch back on the buffer for retry, and does not advance lastFlush. A rejected LTRIM after a successful push is reported without re-sending the batch.
Affected versions
@mastra/loggers workspace source 1.3.9-alpha.0. Node.js 24.21.0, pnpm 11.21.0, Linux. The reproduction mocks fetch; no live Redis is required.
Fix steps
0 of 2 done
Your check marks stay in this browser only.
How to check it worked
- When the pipeline returns a
WRONGTYPEerror onLPUSH,_flush()rejects, the record stays inlogBuffer, and destroy does not report success for that batch.
If it still fails
- No published release tag contains pull request 27480. Tag
@mastra/core@1.78.0was compared against merge4d7d50fcfaceand does not contain it. - A rejected
LTRIMafter a successfulLPUSHis not re-sent, so those records are not duplicated.
Sources and credit
Summarized in our own words from these public reports. Credit goes to their authors.
Provided as is, without warranty. Try changes in a non-production environment and back up first. Security-related steps: verify against the official docs. Terms · Request removal or attribution change
Hit an error we don't cover? Submit it