Customer phone approvals for native Dify Human Input workflows

[aadilghani1]

Hi, I’m Aadil from Pushary. We built a small application-side example for Dify’s native Human Input API: pause an order workflow, request the customer’s decision on their enrolled phone, and resume the same Dify run before executing a protected backend callback.

Runnable example, importable DSL, and checks

The important boundary is that a native Dify form submission is not itself proof of the intended customer’s approval. The example keeps business effects out of the Dify graph. Pushary’s existing Python SDK binds the customer, tenant, run, workflow version, form and exact order parameters to a one-use execution permit. The callback consumes that permit, submits the native form, verifies the resumed run’s output, then writes a local SQLite test order. It never charges or ships anything.

The worker exits while approval is pending; a new process resumes from saved state. Denials, expiry, changed parameters, competing native submitters and uncertain responses do not automatically execute or retry the business effect.

Validation: Dify Cloud import/publication, Studio pause → approve → resume, and an authenticated Service API pause/form check passed. Automated checks exercise real Graphon 0.7.0 snapshots and the published Pushary SDK with simulated hosted services, including duplicate workers and crash/lost-response cases. Phone notification receipt was confirmed, but the complete live phone-answer → API-resume path was not exercised; the README states this limitation. Temporary test keys were revoked.

This is an independently maintained example, not a Dify Marketplace plugin or official integration. The guide includes its trust assumptions and recovery limits. Feedback on the Human Input API usage and recovery boundary would be welcome.

[gomission]

Keeping the business effect behind the permit-protected callback makes the native-form boundary clear. I read review.py and the example’s recovery limits; you already cover duplicate workers and lost responses, so the interesting next comparison seems to be the independent evidence used to resolve an uncertain backend effect.

In Mission’s reference workflow, a provider commit followed by a lost response is recovered through a separate provider lookup and receipt readback. Testing that exposed a race: an older worker’s eventual error could overwrite a newer worker’s verified completion. We fixed both state and receipt writes and published the reproduction and recovery checks. That is a local synthetic proof, not a Dify or Pushary integration.

Would you be interested in a small side-by-side trial using your SQLite order example: terminate after order commit but before returning the result, then restart and compare the order count and reported outcome? I can help prepare the checkpoint mapping. No live payment, shipment or phone service is needed for that comparison; your permit mechanism stays in place.

[aadilghani1]

Thanks — the distinction between preventing a duplicate and independently confirming the outcome was useful. We extended the SQLite example around exactly that checkpoint.

The updated check commits the order and its exact-parameter receipt, terminates the worker before the callback returns, then starts a fresh worker. Without lookup, restart still stops at the closed native form. With read-only backend lookup, it reports released with recovered: true; the order and receipt counts both remain one. The permit is not reset or consumed again.

We also added the race you described: worker A commits and waits, worker B reads back completion, then A receives its delayed error. A rechecks the backend before reporting its SDK outcome; the committed order/receipt remain unchanged and another restart still reports completion. Corrupt, mismatched, incomplete and legacy evidence stop for reconciliation. A receipt-write failure rolls back the order transaction.

The checkpoint mapping and runnable check are in the example README and check_review.py.

One explicit boundary: a hard-killed worker can leave Pushary's hosted execution receipt marked running. This lookup verifies the backend outcome; it does not repair that hosted receipt. These are local SQLite/Graphon checks with simulated hosted HTTP, not a Mission integration or live Dify/phone recovery proof.

That gives us a concrete mapping for your proposed comparison. Does it capture the uncertain-effect checkpoint you intended, or is there another interleaving you would like us to include?

[gomission]

Yes — this captures the uncertain-effect checkpoint we intended, including the delayed-error interleaving. I independently reran check_review.py at f6759b2 with the pinned dependencies; the checks passed, including commit → process death → fresh-worker readback and B recovering before A receives its late error.

The decisive assertions are there: one order and one exact-parameter receipt, recovery without another permit consumption, and subsequent restart still confirming completion. The transaction rollback when receipt persistence fails is also a useful distinction: this SQLite backend can commit the effect and its evidence atomically.

The hosted-receipt boundary is clear. I would preserve both facts in any operator-facing recovery result: backend outcome confirmed; hosted execution receipt may still need reconciliation. Resolving the latter must not require repeating the order.

No additional interleaving is needed to answer this comparison. This establishes the local SQLite/Graphon checkpoint with simulated hosted HTTP; Mission integration and live Dify/phone recovery remain separate, unverified steps. Thanks for turning the suggestion into runnable checks and documenting that boundary explicitly.