Skip to content

Worker-safety check: fixes from review of the default-on change - #10

Merged
HalRiveria merged 1 commit into
mainfrom
fix/worker-check-followups
Oct 28, 2026
Merged

HalRiveria merged 1 commit into
mainfrom
fix/worker-check-followups

Conversation

@HalRiveria-Bot

Copy link
Copy Markdown
Collaborator

Follow-ups to #5, from a review after it merged.

What was wrong, and what changed:

  • Shared collections could crash a run. With -NextJobProvider, the scriptblock scan runs while earlier workers are going. A results sink shared by every job (a synchronized ArrayList or hashtable) threw "Collection was modified" and stopped the run. Such a value is now skipped instead.
  • Big arrays were walked per job. A byte[] of file contents or a large string[] cost a PowerShell loop over every element before each worker started. Collections whose element type can't hold a scriptblock aren't walked now.
  • Nested scriptblocks got through. The scan looked one level deep, so @(@{ Run = { ... } }) passed. It now looks three levels deep and into [pscustomobject] properties.
  • Get-Command cost on every call. The check ran Get-Command for each command name, and an unknown name searched every installed module. That happened on every Invoke-PkRunspaceJobs call, now that the check is on by default. It now reads the Alias: and Function: drives.
  • Module functions were always trusted. Worker rules: allow cmdlets, check by default, refuse scriptblock job values #5 exempted any function from a module, so one imported by path, which a worker can't load by name, failed at runtime instead of being refused. It's flagged again, with a message saying to put the module on $env:PSModulePath or share the function.
  • Storing a scriptblock got the run refused. $list.Add($sb), $map.Add($k, $sb) and $queue.Enqueue($sb) were flagged as delegates. Collection-storage methods are now exempt. The README notes the one case this misses (a collection typed to hold delegates).
  • Alias coverage. Worker rules: allow cmdlets, check by default, refuse scriptblock job values #5 dropped the harness's alias-resolution assertions; a MissingFunction-through-alias case is back.

Testing. 188 assertions pass on Windows PowerShell 5.1, and on PowerShell 7.6 when merged with #6. Six of the new assertions fail against main's kit:

  • storage methods;
  • a module imported by path;
  • a scriptblock two levels down;
  • a [pscustomobject] property;
  • a 20 MB byte[] taking 1.5s against under 1s;
  • a concurrently modified sink throwing "Collection was modified".

The Get-Command change has no timing assertion, since a threshold would be flaky on CI.

🤖 Generated with Claude Code

- The job-value scan no longer throws on a collection running workers
  are changing (a shared results sink with -NextJobProvider); it skips
  it instead of failing the run.
- Typed collections that can't hold a scriptblock (byte[], string[],
  List[int]) aren't walked, so big data job values don't cost a
  PowerShell loop per job.
- The scan looks three levels deep and into [pscustomobject]
  properties, so @(@{ Run = {...} }) is caught.
- Command lookups read the Alias: and Function: drives instead of
  Get-Command, which searched every installed module for unknown names
  on every call.
- A function from a module imported by path (not loadable by name in a
  worker) is flagged again, with a message saying how to fix it.
- Storing a scriptblock in a collection (.Add, .Enqueue, ...) is no
  longer flagged as a delegate.
- Harness: alias-to-unshared-function coverage is back.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@HalRiveria
HalRiveria merged commit c5da070 into main Oct 28, 2026
1 check passed
@HalRiveria
HalRiveria deleted the fix/worker-check-followups branch October 28, 2026 07:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants