@synopackageland/sdk 0.10.6 → 0.10.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synopackageland/sdk",
-  "version": "0.10.6",
+  "version": "0.10.8",
   "description": "Frontend SDK for DSM packages built with synopkgland: headless client and Vue components",
   "license": "MIT",
   "homepage": "https://github.com/synopackageland/syno-pkg-land-sdk/tree/main/ts#readme",

package/spec/protocol/v1/README.md

@@ -112,10 +112,11 @@ browser waits 2 seconds past the request (`timeouts.json` holds the values).
   and was not started in the last 10 seconds, yet whose executor does not
   listen: it is not approved, awaits approval after an upgrade, or failed.
   `retryable` says that nothing was sent, not that waiting helps: a browser
-  client repeats `APP_STOPPED`, `APP_STARTING` and `EXECUTOR_STARTING` on its
-  own, but shows `EXECUTOR_UNAVAILABLE` as the approval state at once, since
-  only an administrator's approval (which also restarts the executor) changes
-  it.
+  client repeats `APP_STARTING` and `EXECUTOR_STARTING` on its own for a few
+  seconds (the DSM window: 4 s), since a start ends by itself, but shows
+  `APP_STOPPED` at once, since only the user starts a stopped package, and
+  shows `EXECUTOR_UNAVAILABLE` as the approval state at once, since only an
+  administrator's approval (which also restarts the executor) changes it.
 
 ## Status
 
@@ -129,6 +130,19 @@ executor would refuse is never shown as ready. While a due start step runs
 `"starting"` and both digests. The executor MUST NOT report the SDK version; the binary
 digest MUST change only when the executor source changes.
 
+Since 0.10.8, `status` also answers `tasks`, the executor's own readback of
+its approval tasks (`../../scheduler/v1`): `{"state", "checked_at"}`. `state`
+is `checking` until the first readback after the executor started ends, then
+`ready` (both tasks are exactly the canonical ones under this executor's
+policy digest), `stale` (a `ready` readback older than 15 minutes) or `failed`
+(any other verdict, or DSM did not answer within 150 seconds). `checked_at`
+(RFC 3339, UTC, the NAS clock) is when that readback started; `checking` has
+none. The executor reads back at start, every 10 minutes after a pass and
+every minute after a failure; a `stale` status starts a readback. The
+executor judges freshness itself, so a client need not compare `checked_at`
+with its own clock. An older executor answers no `tasks`: a client then reads
+the tasks back itself.
+
 ## Application Portal
 
 Since 0.9.6. A policy MAY carry `"portal": {"application": "<display name>",