tursodatabase/libsql

Recover client from server restarts when handling batons?

Open

#1,856 opened on Nov 29, 2024

View on GitHub
 (2 comments) (0 reactions) (0 assignees)C (16,744 stars) (490 forks)batch import
enhancementhelp wantedquestionremote protocol

Description

Currently, I think that when a client holds a server-issued baton and attempts to send it back after a server restart, the request fails with a BatonInvalid error. This error breaks the client's workflow and requires manual intervention.

If this turns out to be the case, let's fix that so thatif a BatonInvalid error occurs and no transaction is in progress, the client should:

  • Automatically restart the stream
  • Obtain a new baton from the server
  • Continue normal operation

Contributor guide

Tech stack
csql
Domain
backenddatabase
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
Understanding of libSQL client server protocolFamiliarity with baton mechanismKnowledge of error handling in C
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
35
Research direction
Investigate the current handling of BatonInvalid errors in the client code. Examine the client's error recovery logic, particularly in the context of server restarts. Look into the libSQL client source code, likely in the client library files, to identify where batons are sent and how errors are propagated. Consider implementing automatic stream restart and baton re acquisition upon BatonInvalid when no transaction is active.