chore: document profiling and other followups, and stuff
idfk
This commit is contained in:
@@ -9353,6 +9353,7 @@
|
|||||||
"name": "expected_revision",
|
"name": "expected_revision",
|
||||||
"required": true,
|
"required": true,
|
||||||
"schema": {
|
"schema": {
|
||||||
|
"minimum": 1,
|
||||||
"type": "integer"
|
"type": "integer"
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
|
|||||||
@@ -82,9 +82,57 @@ Defer these slices until the active sequence exposes a concrete need:
|
|||||||
inspection for native subgraphs
|
inspection for native subgraphs
|
||||||
- Investigate protocol-native progress or streaming only if polling through
|
- Investigate protocol-native progress or streaming only if polling through
|
||||||
`wf run watch` proves inadequate
|
`wf run watch` proves inadequate
|
||||||
|
- Profile run latency before adding instrumentation: separate test setup,
|
||||||
|
graph execution, validation/serialization, and result printing in the slow
|
||||||
|
rewrite example. Capture a flame graph or time-oriented profile before
|
||||||
|
attributing cost to `model_validate`. Use the measurements to scope per-node
|
||||||
|
timing, wall-clock correlation timestamps, and possible OpenTelemetry
|
||||||
|
integration; preserve monotonic duration measurement as a separate concern.
|
||||||
- Continue [`OpenAPI capability sources`](openapi_capability_source.md) when a
|
- Continue [`OpenAPI capability sources`](openapi_capability_source.md) when a
|
||||||
real non-MCP source requires them
|
real non-MCP source requires them
|
||||||
|
|
||||||
|
## Scheduling follow-ups
|
||||||
|
|
||||||
|
These are separate improvement slices, not reopened scheduling blockers or
|
||||||
|
new prerequisites for the active fork/gather sequence. Plan them explicitly
|
||||||
|
rather than expanding review-cleanup waves.
|
||||||
|
|
||||||
|
- **Persistence and concurrency design:** concentrate ownership, transaction,
|
||||||
|
and cancellation responsibilities behind explicit guarantees. Keep
|
||||||
|
filesystem roots and lock mechanics inside the file-backed implementation;
|
||||||
|
preserve durable admission, attempt identity, scoped recovery, and
|
||||||
|
join-before-ownership-release tests. Do not introduce an ORM or silently
|
||||||
|
optional transaction guarantees as part of this design work.
|
||||||
|
- **Responsiveness and scale:** first address synchronous schedule-admin work
|
||||||
|
on the event loop with cancellation-safe, joined execution and shutdown
|
||||||
|
coordination. Then measure historical-run scans before planning occurrence
|
||||||
|
indexes or active-run indexes; any index needs its own recovery contract.
|
||||||
|
- **Python scheduling ergonomics:** design client-owned occurrence objects
|
||||||
|
and pages, computed next-run information, and the placement of schedule
|
||||||
|
mutation methods. Keep calendar behavior library-owned and distinguish a
|
||||||
|
predicted next occurrence from guaranteed execution under capacity and
|
||||||
|
overlap policies.
|
||||||
|
|
||||||
|
## Thesis and evidence work
|
||||||
|
|
||||||
|
Continue the
|
||||||
|
[`system design and implementation thesis`](thesis/system-design-implementation.md)
|
||||||
|
alongside runtime work. Preserve its focus on application purpose, general
|
||||||
|
UI/UX, and execution semantics before introducing implementation details;
|
||||||
|
explain artifacts and deployments in that progression. Revisit diagrams for
|
||||||
|
standalone clarity and keep implemented capabilities separate from future
|
||||||
|
product directions.
|
||||||
|
|
||||||
|
The companion shell-backed assistant has a local execution backend; its chat
|
||||||
|
interface is under development. Workflow-client integration and agent-driven
|
||||||
|
authoring remain future evaluation work. Rerun the agent evaluation when that
|
||||||
|
integration is ready; retain the old 36-trial material as historical evidence
|
||||||
|
rather than presenting it as validation of the new experience.
|
||||||
|
|
||||||
|
Resolve the missing generated thesis PDF fixtures separately: decide whether
|
||||||
|
tests generate them or the reproducible build supplies them, then document
|
||||||
|
and test that policy. Do not weaken asset checks merely to make CI green.
|
||||||
|
|
||||||
## Durable platform constraints
|
## Durable platform constraints
|
||||||
|
|
||||||
These rules describe current boundaries. New work should preserve them.
|
These rules describe current boundaries. New work should preserve them.
|
||||||
|
|||||||
+1
-1
@@ -42,7 +42,7 @@ dev = [
|
|||||||
]
|
]
|
||||||
|
|
||||||
[tool.pytest.ini_options]
|
[tool.pytest.ini_options]
|
||||||
addopts = "-p no:cacheprovider -n 8"
|
addopts = "-p no:cacheprovider -n auto --maxprocesses=8"
|
||||||
pythonpath = ["."]
|
pythonpath = ["."]
|
||||||
asyncio_mode = "auto"
|
asyncio_mode = "auto"
|
||||||
markers = ["slow: slow subprocess/integration tests (deselect with '-m \"not slow\"')"]
|
markers = ["slow: slow subprocess/integration tests (deselect with '-m \"not slow\"')"]
|
||||||
|
|||||||
@@ -60,6 +60,7 @@ def build_input(context: Context):
|
|||||||
|
|
||||||
def test():
|
def test():
|
||||||
assert 240 - 135 + 20 >= 120, "my math!"
|
assert 240 - 135 + 20 >= 120, "my math!"
|
||||||
|
|
||||||
d = gacha.execute(
|
d = gacha.execute(
|
||||||
build_input(context)(
|
build_input(context)(
|
||||||
20, # lets be optimistic
|
20, # lets be optimistic
|
||||||
|
|||||||
Reference in New Issue
Block a user