livepeer / livepeer/go-livepeer
AI jobs getting `senderNonce: too many values`
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 586
- Forks
- 226
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 19
Description
**Describe the bug**
When sending AI jobs for expensive models (such as DeepSeek), or in the case of LLM pipeline, sending large `max_tokens` parameter such as 163K tokens, it causes a lot of payment tickets to be sent at once.
The Orch will show this message.
```
Error receiving ticket sessionID=33_meta-llama/Meta-Llama-3.1-8B-Instruct recipientRandHash=7905016d8d201e4bb0d13f78234e107018b2effe42343325691a55844a1d54cf senderNonce=178: invalid ticket senderNonce: too many values sender=0x5bE44e23041E93CDF9bCd5A0968524e104e38ae1 nonce=178
```
There is a nonce cap of 150 currently. We need to allow infinite nonce count to be accepted by the Orch, or some way to manage this limit.
For instance, if LLM context windows keep increasing or price keep getting higher, which I believe it will, we need higher throughput of tickets to be redeemed.
This is also prevalent when multiple jobs are sent at the same time, the ticket nonce stacks up and will reach the limit quickly.
**To Reproduce**
Steps to reproduce the behavior:
1. Start AI Gateway
2. Start Orchestrator with 7 USD per 1 million tokens
3. Send LLM request with 163K `max_tokens` parameter
4. See error
Contributor guide
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.
Research direction
Start with the Orchestrator's ticket-receiving path and reproduce the failure through the AI Gateway using a 163K max_tokens request or several concurrent jobs. Trace where the senderNonce cap of 150 is enforced; done means these payment tickets can be processed without the "too many values" error while the nonce limit is safely managed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- payments
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100