Skip to content

hierarchical con/duct collection/reporting #397

@yarikoptic

Description

@yarikoptic

if I run overall con-duct over some long process but then additional more specific con-duct's within.

  • I guess it also would not work "properly" ATM for reporting at the "root level" as children con-ducts would gain their own session ids, so root process will not count children processes (which is kinda like a feature if we solve next one):
    • actually since we report wallclock -- that is shown ok:
❯ duct bash -c 'sleep 1; duct sleep 2'
...
❯ con-duct ls
PREFIX                                  COMMAND                       EXIT_CODE WALL_CLOCK_TIME PEAK_RSS
.duct/logs/2026.02.22T10.59.16-1723653_ sleep 2                       0         2.001 sec       2.2 MB  
.duct/logs/2026.02.22T10.59.15-1723650_ bash -c sleep 1; duct sleep 2 0         3.082 sec       23.0 MB 
  • when child process runs we need to inform parent process, so it would know to look/collect stats from children processes
    • I think it still remains useful to separate child from parent
    • also worth considering triple- and further nesting of duct invocations, so solution should be generic.
  • implementation idea(s):
    • child process after detecting running in parent one, would inform the parent by placing its {parent_output_prefix}_child-{pid}_info.json upon start and finalizing upon completion with its summary
      • we need to add storing session_id within out _info.json files. and if we detect that runs within some other duct, storing its parent_session_id.
      • this should be sufficient to reconstruct full tree of invocations
    • have an option for "full archival of inherited children stats" to place also its other files (_stats and outputs) there as well. (note that then we would require rewriting the corresponding _info.json to reflect placement and renaming of those files which is not needed in default case)
  • con-duct ls then could report "own" and "total" time in case of children sessions, and also number of children sessions and depth (after analysis).
    • -r could then list their details explicitly

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions