make subscription handling more robust: persist state, follow protocol spec more closely, etc.

[derhuerst]

I will update this tracking Issue with the current state as changes are made.

improve general state handling

vdv-453-client/index.js

Line 188 in 8104cfd

ok: true, // todo: are we ever not okay?

persist state

vdv-453-client/index.js

Lines 151 to 160 in 0ace9f3

	// Technically, we don't need globally unique subscription IDs.
	// > 5.1.1 Überblick
	// > Eine AboID ist innerhalb eines jeden Dienstes eindeutig.
	const getNextAboId = () => String(10000 + Math.round(Math.random() * 9999))
	// todo: "Wird eine AboAnfrage mit einer AboID gestellt und es existiert bereits ein Abonnement unter dieser Bezeichnung, so wird das bestehende Abonnement überschrieben." – warn about this? does it apply across services?
	// todo: persist AboIDs across client restarts, reinstate fetch timers after restarts?
	// service -> AboID -> subscriptionAbortController
	const subscriptions = Object.fromEntries(
	SERVICES.map(svc => [svc, new Map()]),
	)

follow protocol spec more closely

vdv-453-client/index.js

Line 155 in 0ace9f3

// todo: "Wird eine AboAnfrage mit einer AboID gestellt und es existiert bereits ein Abonnement unter dieser Bezeichnung, so wird das bestehende Abonnement überschrieben." – warn about this? does it apply across services?

vdv-453-client/index.js

Lines 196 to 202 in 0ace9f3

	// todo: provide AktiveAbos if `clientStatusAnfrage.$.MitAbos` has value `true`
	// > 5.1.8.3 ClientStatusAnfrage
	// > Beispiel 3: Antwort des Clients: Dienst verfügbar, Client initialisiert gerade und will keine Auskunft zu den aktiven Abonnements geben:
	// > 5.1.8.3 ClientStatusAnfrage
	// > […]
	// > Stellt der Server einen Unterschied zwischen seiner Abonnementliste und der Liste vom Client, kann der Server entweder stillschweigend den Unterschied beseitigen indem er die nicht aus der Clientsicht aktiven Abonnements löscht und die aus der Clientsicht aktiven Abonnements registriert und anfängt für diese Daten bereitzustellen oder er setzt den StartDienstZst in seiner StatusAntwort auf die aktuelle Zeit und erzwingt somit die Neuinitiali- sierung des Clients. Der zweite Weg wird empfohlen.
	// > Ist die Struktur AktiveAbos leer, hat der Client keine aktiven Abonnements. Falls der Server doch welche kennt, sollen diese stillschweigend deaktiviert werden.

vdv-453-client/index.js

Line 188 in 8104cfd

ok: true, // todo: are we ever not okay?

vdv-453-client/index.js

Lines 424 to 426 in 8104cfd

	// todo:
	// > 5.1.4.1 Datenübertragung anfordern (DatenAbrufenAnfrage)
	// > Wurde bereits eine DatenAbrufenAnfrage vom Client an den Server versandt, so ist für diese vom Client eine DatenAbrufenAntwort abzuwarten (Antwort, oder Timeout), bevor erneut eine DatenAbrufenAnfrage versandt wird. Es wird daher empfohlen keine weitere DatenAbrufenAnfrage zu stellen, solange noch eine DatenAbrufenAnfrage aktiv ist.

vdv-453-client/lib/server.js

Lines 201 to 211 in 8104cfd

	bestaetigung ? x('Bestaetigung', {
	Ergebnis: _ok ? 'ok' : 'notok',
	Fehlernummer: fehlernummer + '',
	// todo: use Zst from req?
	Zst: getZst(),
	}) : null,
	status ? x('Status', {
	Ergebnis: _ok ? 'ok' : 'notok',
	// todo: use Zst from req?
	Zst: getZst(),
	}) : null,

vdv-453-client/index.js

Lines 237 to 238 in 0ace9f3

// todo: send StatusAnfrage periodically, to detect server hiccups

// > Verliert der Server seine Abonnement-Daten, so ist dies zunächst vom Client aus nicht fest- stellbar. DatenBereitAnfragen bleiben zwar aus, aber dies kann nicht vom normalen Betrieb unterschieden und somit der Absturz des Servers nicht festgestellt werden. Um diesen Fall zu erkennen, sind zusätzliche, zyklische Anfragen vom Typ StatusAnfrage (5.1.8.1) zum Server zu senden. Innerhalb der StatusAntwort (5.1.8.2) gibt der Server den Zeitstempel des Dienststarts an. Fand der Dienststart nach der Einrichtung der Abonnements statt, so muss vom Verlust der Abonnements ausgegangen werden. Es ist nun zu verfahren wie beim Client-Datenverlust: Löschen und Neueinrichtung aller Abonnements.

vdv-453-client/index.js

Lines 261 to 262 in 0ace9f3

	// todo: warn if DatenGueltigBis < aboParams.VerfallZst?
	// > (optional) Ende des Datenhorizontes des Datenproduzenten. Entfällt, wenn Anfrage vollständig im Datenhorizont liegt.

add more events about what's happening

vdv-453-client/index.js

Lines 184 to 185 in 8104cfd

	// todo: expose value of `StartDienstZst` child?
	// todo: expose value of `DatenVersionID` child?

vdv-453-client/index.js

Lines 261 to 262 in 0ace9f3

	// todo: warn if DatenGueltigBis < aboParams.VerfallZst?
	// > (optional) Ende des Datenhorizontes des Datenproduzenten. Entfällt, wenn Anfrage vollständig im Datenhorizont liegt.

improve debug logging

vdv-453-client/index.js

Line 164 in 8104cfd

// todo: debug-log

vdv-453-client/index.js

Line 226 in 8104cfd

// todo: otherwise warn-log unexpected tag?

vdv-453-client/index.js

Line 253 in 8104cfd

// todo: otherwise warn-log unexpected tag?

vdv-453-client/index.js

Line 518 in 8104cfd

// todo: otherwise warn-log unexpected tag?

vdv-453-client/lib/server.js

Line 131 in 8104cfd

// todo: trace-log request body if it is small enough

vdv-453-client/lib/server.js

Line 138 in 8104cfd

// todo: timing

vdv-453-client/lib/server.js

Line 154 in 8104cfd

// todo: trace-log response body if it is small enough

vdv-453-client/lib/send-request.js

Line 143 in 8104cfd

// todo: make sure this message appears in the error thrown by `request()`

vdv-453-client/lib/send-request.js

Lines 171 to 175 in 8104cfd

	logger.debug({
	...logCtx,
	// todo: timing
	}, 'received response')
	// todo: trace-log response body if it is small enough

vdv-453-client/lib/send-request.js

Line 223 in 8104cfd

// todo: make err.message more helpful, e.g. by building a custom error

[derhuerst]

As of vdv-453-client@3, the subscription state is now persisted in Redis.