Dependencies, Fragments, and Callbacks
Dependencies
> requires: Request Name
Dependencies create a DAG so setup requests run before dependents. Dependency captures require the
referenced request to be declared in > requires: so the planner can guarantee the upstream result
exists.
Use dependencies when later requests need values or ordering guarantees from earlier requests.
Fragments
<< ./fragments/common_schema_types.hen
[ FEATURE_ENABLED == true ] << ./fragments/extra_assertions.hen
<< path.henimports another Hen file before parsing- fragment paths resolve relative to the importing file
- guards can skip a fragment import entirely
- fragments can contribute reusable declarations or request-local snippets
Callbacks
! callback code
! ./path/to/callback_file.sh
! some command -> $VARIABLE_NAME
- callback assignments require whitespace around
-> - assignment form suppresses stdout and exports the captured value
- callbacks run after request execution
Callbacks are a good fit for side effects such as notifications, local file writes, or shell-based post-processing that should happen after a request completes.
Combined Pattern
<< ./fragments/export_shapes.hen
---
Create export
POST {{ API_ORIGIN }}/exports
~~~json
{"format":"csv"}
~~~
^ & status == 202
& body.id -> $EXPORT_ID
---
Wait for export
> requires: Create export
GET {{ API_ORIGIN }}/exports/{{ EXPORT_ID }}
^ & status == 200
^ & body === ExportStatus
! ./scripts/notify_export_ready.sh
In that flow, the fragment can contribute shared variables or schema targets such as
API_ORIGIN and ExportStatus, the first request captures $EXPORT_ID, the second request uses
that capture through an explicit dependency, and the callback script runs after the dependent
request completes.
Dependencies, fragments, and callbacks work well together when you want:
- a reusable shared preamble
- a setup request that exports values
- a later request that consumes those values
- a callback that ships the result elsewhere after the request completes