@ductape/mcp 0.2.3 → 0.2.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.js +39 -3
- package/package.json +1 -1
package/dist/index.js
CHANGED
|
@@ -2844,6 +2844,13 @@ FALLBACKS — automatic provider switching on failure:
|
|
|
2844
2844
|
fallback.dispatch [{ product, env, tag, input, schedule? }]
|
|
2845
2845
|
|
|
2846
2846
|
HEALTHCHECKS — continuous probe with failure notifications:
|
|
2847
|
+
Scheduled probes have a platform-owned fallback runner in the Ductape proxy. A local SDK monitor
|
|
2848
|
+
may also run them: while it consistently persists a fresh lastChecked record, the proxy defers
|
|
2849
|
+
that product/env/check. The proxy freshness window accounts for the SDK's batched backend status
|
|
2850
|
+
flush (currently five minutes), not only the shorter probe interval. If records stop arriving and
|
|
2851
|
+
the freshness window expires, the proxy automatically takes over. Do not instruct users to
|
|
2852
|
+
disable the proxy fallback when using a local monitor.
|
|
2853
|
+
|
|
2847
2854
|
Workbench definition shape:
|
|
2848
2855
|
{
|
|
2849
2856
|
tag: "payment-health",
|
|
@@ -2851,7 +2858,7 @@ HEALTHCHECKS — continuous probe with failure notifications:
|
|
|
2851
2858
|
probe: { type: "app", app: "stripe-app", event: "ping" },
|
|
2852
2859
|
interval: 30000, // ms between checks
|
|
2853
2860
|
retries: 3,
|
|
2854
|
-
envs: [{ slug: "prd", input: {} }],
|
|
2861
|
+
envs: [{ slug: "prd", input: { path: "/health" } }],
|
|
2855
2862
|
onFailure: {
|
|
2856
2863
|
notifications: [{ notification: "ops-alerts", message: "payment-down",
|
|
2857
2864
|
channels: { email: { recipients: ["ops@example.com"] } } }],
|
|
@@ -2862,8 +2869,37 @@ HEALTHCHECKS — continuous probe with failure notifications:
|
|
|
2862
2869
|
health.check [{ product, env, tag }] → same as run
|
|
2863
2870
|
health.status [{ product, env, tag }] → current health status
|
|
2864
2871
|
|
|
2865
|
-
Probe types: app | database | feature | graph |
|
|
2866
|
-
|
|
2872
|
+
Probe types: app | database | feature | graph | events | storage
|
|
2873
|
+
Canonical Events probe:
|
|
2874
|
+
{ type: "events", events: "statecraft-events", event: "health" }
|
|
2875
|
+
Do not create new probes with type/field message_broker or messageBroker; those names are deprecated
|
|
2876
|
+
compatibility aliases.
|
|
2877
|
+
|
|
2878
|
+
APP HEALTHCHECK SETUP — REQUIRED DISCOVERY AND VALIDATION
|
|
2879
|
+
An app healthcheck is not a generic URL ping. It invokes one action belonging to an app already
|
|
2880
|
+
connected to the product. Before creating it:
|
|
2881
|
+
1. Read the product's connected apps with:
|
|
2882
|
+
ductape_cli("products components get --product-tag <product> --type apps --json")
|
|
2883
|
+
2. Select a connected app by its product access tag. Never invent or use an unconnected app tag.
|
|
2884
|
+
3. Inspect that connected app's available actions/schema using the app/schema tools. Select an
|
|
2885
|
+
existing action intended to be safe for repeated health probes.
|
|
2886
|
+
4. Build a payload matching that action's required input schema for every selected product
|
|
2887
|
+
environment. Payloads belong in envs[].input and may differ by environment.
|
|
2888
|
+
5. Create the resource with:
|
|
2889
|
+
ductape_cli("resources health create --tag <product> -f <healthcheck.json> --json")
|
|
2890
|
+
6. Fetch the created healthcheck and verify probe.app, probe.event, and every env payload target;
|
|
2891
|
+
then run one immediate check and inspect status before relying on the schedule.
|
|
2892
|
+
|
|
2893
|
+
Required app probe shape:
|
|
2894
|
+
{
|
|
2895
|
+
probe: { type: "app", app: "<connected-app-access-tag>", event: "<existing-action-tag>" },
|
|
2896
|
+
envs: [{ slug: "<product-env>", input: { ...actionPayload } }]
|
|
2897
|
+
}
|
|
2898
|
+
Do not create an app healthcheck when the app, action, or required payload cannot be verified.
|
|
2899
|
+
The platform must reject missing/unconnected apps, unknown actions, and invalid action payloads;
|
|
2900
|
+
never interpret a successful create response alone as proof that the probe is runnable.
|
|
2901
|
+
|
|
2902
|
+
Failure actions: notification channels, HTTP webhooks, and/or Events emit — all can
|
|
2867
2903
|
be configured simultaneously on the same healthcheck.
|
|
2868
2904
|
Input template references: $Input{field} → maps declared input to the probe's action input.
|
|
2869
2905
|
Provider status: available | unavailable
|