Errors and offline
A call fails with a TinylibError, an Error with a code that says what happened and a message you can show the user. A refusal from your rules carries your own sentence.
This form joins a room by its short code, and shows a code that matches no room as the field's own error:
Each call's reference lists the codes it can fail with, and any call that reaches Tinylib's servers can also fail with failed.
A call given arguments it can't take, such as tinylib.places.go('/game'), throws a TypeError, or rejects with one if it's asynchronous. Its message is for you, not the user.
Closing one of Tinylib's sheets without choosing isn't an error. block and report resolve false, user.manageSettings resolves with the settings unchanged, and the other calls that open a sheet resolve when it closes:
While a room your app has open can't reach Tinylib, Tinylib shows so over your app, so your app doesn't show its own.
tinylib.connection.online says whether Tinylib's servers can be reached, and onChange calls your function when that changes:
A call that needs a connection rejects with offline at once when there's none. The others work with what the device keeps:
Writes and reminders made offline are sent when the connection returns. tinylib.data.onChange reports a write that fails once it arrives.
Your app opens offline once it has opened online on that device, except that Safari may delete its copy (Platforms).
When the connection drops, an open room disconnects, and Tinylib reopens it with the current view when the connection returns. Meanwhile, room.act rejects with offline outside an offline kind, and events the rules emit and other members' relays are missed.
A request that loses its connection after it left the device rejects with offline, and Tinylib can't tell whether it arrived. A room.act may have run, and once the room reopens, its view shows whether it did. A rooms.create may have made a room, so check tinylib.rooms.list() before creating another.
An offline kind doesn't have this problem: the device sends each action until the room has it, and the room runs each one once.
When the rules throw, or an input runs past 50 milliseconds of CPU time, the input changes nothing and sends nothing. If it was a member's rooms.create or room.act, the call rejects with failed. An error never ends a room.
A join or a leave still happens when its handler throws, and only the rules' changes from it are dropped. The member is then in the room but not in the state, so keep join and leave from throwing, and write your other handlers to cope with a member the state doesn't know.
When something a handler asks for can't be done, such as a notification whose text is past 300 characters, Tinylib skips it and keeps the rest of the input. The error shows on your developer page.
In npx tinylib-sdk dev, the inspector shows everything your rooms do as it happens, and console.log in your rules prints to the browser's console. In live rooms, console.log goes nowhere.
Errors from live rooms show on your app's developer page, each with its kind, its input, the version, how many times it happened, and the line in your files where it happened. Tinylib never shows you a room's state or an input's data, and the Developer Terms forbid putting people's data in error messages.