Skip to content
pi-straw-boss

0.75.1

This release fixes cars of more than 16 tickets, which an integrator could not receive or return, and says how to recover a forward lost to a server restart.

A car’s tickets are kept whole: an integrator can receive and return a car with more than 16 tickets. A forward lost to an sb server restart is told as that, with the way back.

Fixes

Section titled “Fixes”

Todo #154, from a live v3 car (0.74.0) whose slip named 24 tickets: the tower forwarded it, and the integrator’s train_car state=returned was refused with sb: car MP-3627 does not match the forwarded slip: tickets differs from what the slip the tower forwarded says.

  • No silent cut of a car’s identity. The forward record the server keeps of a tower’s forward, the manifest’s car row and the yard page’s car view each cut the car’s tickets to the first 16, while the integrator’s claim (read from the same slip) carried all of them, so any car with more than 16 tickets could be neither received nor returned. They keep the whole list now, and the forward record and the integrator’s claim compare whole lists.
  • One bound for a car’s tickets. A car carries at most 64 tickets, each at most 64 characters (MAX_CAR_TICKETS and MAX_TICKET_CHARS in src/train/spec.ts), the same bound in the slip check, the car file, the evidence file’s car.tickets and the trainboard. A slip over it is refused by train check up front (sb: slip tickets names 70 tickets, and a car carries at most 64: split the car into two or more slips), and the integrator’s received or returned refuses it the same way before anything is written (the server’s forward record keeps only the bound of such a slip), so a sender splits the car whichever way it sends it. The trainboard’s per-car cap was 16 and is 64; the board still shortens a car’s tickets to fit its size cap only when a board is too big for the writer, as it did before, and nothing compares against that board.

Todo #154, second case, live on 0.75.0: the tower forwarded a car slip to an integrator, an install restarted the sb server 8 minutes later, and the integrator’s train_car state=returned was refused with sb: no forward by a tower carries head f7ed84687c6d to this session, which named no cause and no way on.

  • A restart is told, not undone. The server keeps a tower’s forwards in memory only, by design: nothing read from disk is proof of a car’s identity, since a train runs as the same user and can write any file the server can (spec §24, CR-F003). That stays. What changes is the refusal: for 24 hours after the server’s start (as long as a forward is kept), it adds The sb server started at <time> and keeps a tower's forwards in memory only, so a forward made before that is gone with the restart: ask the car's coordinator to send its slip to the tower again (call_tower why=shared); the tower forwards it again, and then the state is set. The tower’s new forward is what restores the car; no file does.
  • The same for the door’s answer. In a project that runs integrators of its own, tower_reply with forward goes only to an integrator the door (boss_open_main with role: "integrator") named for that slip, and that answer is in memory too. A tower run that outlived a restart holds the slip but not the answer: its refusal now adds the server’s start time and says to ask the door again, when the slip came in before the server started.
  • A forward id that is gone. The refusal of a forward id no run holds now says the event is held only while its run lives and for 24 h, and to ask the sender to send the slip again and forward the new id.
  • Before an install. Updating pi-straw-boss restarts the sb server. A car forwarded but not yet received or returned at that moment needs its slip sent again.