Conversation
Adds rollback path so a failed POST /v1/server/push doesn't lose counter state — node/user.go re-injects the slice into core via AddUserTrafficSlice, retried next cycle. - core/interface.go: extend Core interface - core/xray/user.go, core/sing/user.go: per-engine impls - core/selector.go: dispatch - node/user.go: rollback on report failure
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c323f3e21e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "err": err, | ||
| }).Info("Report user traffic failed") | ||
| // Rollback so the next cycle re-reports. | ||
| if rbErr := c.server.AddUserTrafficSlice(c.tag, userTraffic); rbErr != nil { |
There was a problem hiding this comment.
Avoid replaying traffic batches on ambiguous push failures
Re-adding the entire userTraffic slice on any ReportUserTraffic error can overcount usage when the panel has already applied the POST but the client still sees an error (for example, response timeout or connection drop after server-side commit). In that case this rollback path requeues the same deltas and the next successful push reports them again, corrupting accounting/billing totals. The replay needs idempotency (request key/sequence) or stricter error handling that only rolls back when processing is guaranteed not to have happened.
Useful? React with 👍 / 👎.
No description provided.