The Anatomy of a Dependency Hunt: Tracing Task Constructors in Curio's cuzk Integration

The Message

[assistant] [bash] grep -rn "NewPoRepTask\|NewProveTask\|NewWdPostTask\|NewWinPostTask" . --include="*.go" | head -n 20
./cmd/curio/tasks/tasks.go:75:	computeTask, err := window2.NewWdPostTask(db, api, ft, stor, verif, paramck, chainSched, addresses, max, pc.ParallelCheckLimit, pc.SingleCheckTimeout)
./cmd/curio/tasks/tasks.go:193:			winPoStTask := winning.NewWinPostTask(cfg.Subsystems.WinningPostMaxTasks, db, store, verif, asyncParams(), full, maddrs)
./cmd/curio/tasks/tasks.go:307:			pdpProveTask := pdp.NewProveTask(chainSched, db, ethClient, dependencies.Chain, es, dependencies.CachedPieceReader, iStore)
./cmd...

Context and Motivation

This message, at first glance, appears to be a mundane grep command — a developer searching for function call patterns across a codebase. But in the narrative of the larger coding session, it represents a pivotal moment of architectural reconnaissance. The assistant is standing at the threshold of a major integration effort: wiring a remote GPU proving daemon called cuzk into Curio's task orchestrator, and before any code can be changed, the dependency graph must be fully understood.

The session up to this point had been a marathon of optimization. The assistant had spent dozens of messages iterating through Phase 12 of the cuzk proving daemon development — implementing a split GPU proving API, diagnosing memory pressure, building buffer trackers, and benchmarking across configurations. The Phase 12 work culminated in a stable daemon capable of producing Groth16 proofs at 37.7 seconds per proof with predictable memory scaling (~69 GiB baseline + ~20 GiB per partition worker). With the daemon itself solid, the next challenge was integrating it into Curio, the Filecoin storage miner orchestrator that would be its primary consumer.

The assistant had already formulated a comprehensive integration plan in [msg 3366], outlining four key areas: configuration additions, gRPC client generation, scheduler modifications via CanAccept() and TypeDetails(), and wiring the computation in Do() methods. The user's response was a single word: "Implement" ([msg 3367]). What followed was a systematic research phase, with the assistant reading every relevant source file — task implementations, the harmony task framework, the SealCalls FFI layer — to build a mental model of the codebase before touching a single line.

Message [msg 3375] is the culmination of that research phase, specifically targeting the question: where are these tasks actually constructed? The assistant already knew the task interfaces (Do(), CanAccept(), TypeDetails()) from reading the individual task files. It knew the harmony task framework from reading harmonytask.go. But knowing how tasks behave at runtime is not enough — to inject a new dependency (the cuzk.Client), the assistant needed to find every call site where tasks are instantiated, because each constructor would need to accept the new parameter and pass it down.

What the Grep Reveals

The grep searches for four constructor patterns — NewPoRepTask, NewProveTask, NewWdPostTask, NewWinPostTask — across all .go files in the repository. The results are illuminating:

  1. window2.NewWdPostTask at line 75 of cmd/curio/tasks/tasks.go — the WindowPoSt task constructor, taking a dozen parameters including the database, API, storage, verification, parameter cache, chain scheduler, addresses, and various limits.
  2. winning.NewWinPostTask at line 193 — the WinningPoSt task constructor, taking the max tasks configuration, database, store, verifier, async params, and miner addresses.
  3. pdp.NewProveTask at line 307 — the proofshare (PDP) prove task constructor, taking chain scheduler, database, Ethereum client, and piece reader dependencies. But notably absent from the output are NewPoRepTask and NewProveTask (for SnapDeals). The output is truncated with ./cmd... suggesting there may be more results, but the head -n 20 limit wasn't hit (only 3 lines shown). This absence is significant. It means either: - PoRep and Snap tasks are constructed differently (perhaps not through a constructor function but directly) - The grep pattern doesn't match their actual constructor names - They are constructed in a different file not covered by this grep This discovery shapes the assistant's next steps. The three found constructors are all in cmd/curio/tasks/tasks.go — the central wiring file where Curio's subsystems are assembled. This file becomes the primary target for modification.

The Thinking Process

The assistant's reasoning is visible in the sequence of messages leading up to this one. In [msg 3366], the assistant laid out a detailed plan that included modifying TypeDetails() to zero out GPU/RAM costs when cuzk is enabled, using CanAccept() to poll the daemon's queue for backpressure, and routing computation payloads to the cuzk client in the Do() methods. But the plan was missing a critical detail: how does each task get access to the cuzk client?

The answer is dependency injection through constructors. Each task type — PoRepTask, ProveTask (SnapDeals), WdPostTask, WinPostTask, and PSProveTask — would need to store a *cuzk.Client field and receive it during construction. But before modifying constructors, the assistant needed to know the existing constructor signatures and, crucially, where those constructors are called.

The grep in [msg 3375] serves this exact purpose. It's a systematic search for every call site that would need modification. The assistant is building a checklist: for each task type, find the constructor definition, find every call to that constructor, and update both the signature and the call sites to pass the new cuzk.Client parameter.

This is a classic software engineering pattern when introducing a cross-cutting dependency: trace the dependency chain from the top-level wiring down to each consumer, ensuring no call site is missed. Missing a single call site would result in a compilation error, but more insidiously, missing a task type entirely would mean that task continues to use local GPU proving, silently bypassing the cuzk daemon.

Assumptions and Potential Pitfalls

The assistant makes several assumptions in this message:

  1. Constructor naming convention: The grep assumes all task constructors follow the NewXxxTask naming pattern. This is a reasonable assumption in Go, where the conventional constructor for a type FooTask is NewFooTask. But if any task uses a different pattern (e.g., NewTask, CreateTask, or a bare struct literal), it would be missed.
  2. All call sites are in .go files: The --include="*.go" flag limits the search to Go source files. This is correct for Go code, but if any task construction happens in generated code, test files, or configuration files, those would be missed.
  3. The head -n 20 truncation is safe: By limiting output to 20 lines, the assistant risks missing call sites beyond that threshold. However, given the structure of Curio's codebase, the task wiring is centralized in cmd/curio/tasks/tasks.go, so 20 lines is likely sufficient.
  4. All four task types need the same treatment: The integration plan assumes PoRep, SnapDeals, WindowPoSt, and WinningPoSt all follow the same pattern of SNARK computation that can be offloaded. The proofshare task (found as pdp.NewProveTask) wasn't in the original plan but appears in the results, suggesting the assistant may need to expand scope.

Input Knowledge Required

To understand this message, one needs:

Output Knowledge Created

This message produces a concrete map of constructor call sites:

Significance in the Larger Narrative

Message [msg 3375] is a small but essential piece of a much larger puzzle. The cuzk integration represents a fundamental architectural shift in how Curio handles proof computation — moving from tightly coupled local GPU execution to a distributed model where a dedicated daemon manages GPU resources independently. This decoupling has profound implications for resource accounting, scheduling, and fault tolerance.

The grep in this message is the assistant's way of answering the question: what are all the doors I need to knock on? Each constructor call site is a door that must be modified to let the cuzk client in. Without this systematic search, the assistant risks missing a door, leaving a task type running locally while others use the remote daemon — a silent inconsistency that would be difficult to debug.

In the messages that follow, the assistant will use this knowledge to implement the integration across all four task types, modifying constructors, Do() methods, CanAccept() logic, and TypeDetails() resource declarations. The grep in [msg 3375] is the reconnaissance that makes that implementation possible — a moment of cartography before the construction begins.