Add Flow.usingChannel

[adamw]

Ports Flow.usingChannel from jox to ox as requested in issue #396.

Changes

• Added Flow.usingChannel method to create flows with a provided Sink
• Automatically handles channel lifecycle and error propagation
• Includes comprehensive tests for various usage scenarios

Fixes #396

---

Generated with Claude Code

[adamw]

@claude can you also update the docs, as in the original jox pr, in the flows.md file?

[claude]

Claude finished @adamw's task in 1m 10s —— View job

---

Documentation Update

I've added documentation for Flow.usingChannel to the flows.md file.

Tasks

• Read flows.md to understand documentation structure
• Review the implementation of Flow.usingChannel
• Add documentation for Flow.usingChannel to flows.md
• Commit and push changes

Changes Made

Added a new section in doc/streaming/flows.md (after the Flow.usingEmit section) that documents Flow.usingChannel. The documentation includes:

• An example showing how to use Flow.usingChannel with a Sink
• Explanation of how it differs from usingEmit (thread-safe Sink vs thread-unsafe FlowEmit)
• Details about async execution (runs in a forked task)
• Automatic channel lifecycle management (closes on completion, propagates errors)
• Requirement for a concurrency scope

The documentation follows the same pattern as the existing Flow.usingEmit documentation and provides a clear example of concurrent usage with fork.

--- | Branch

[adamw]

@claude the build is failing

[claude]

Claude finished @adamw's task in 2m 6s —— View job

---

Build Failure Fixed

Tasks

• Check CI status to identify failing jobs
• Review error logs
• Identify root cause
• Fix the formatting issues
• Commit and push changes

Root Cause

The build was failing because two files weren't formatted properly according to scalafmt (140 character line limit):

• core/src/main/scala/ox/flow/Flow.scala:12 - Long comment line exceeded character limit
• core/src/main/scala/ox/flow/FlowCompanionOps.scala:52 - Method signature exceeded character limit

Changes Made

• Split the long comment line in Flow.scala to comply with 140 character max
• Reformatted the usingChannel method signature and body in FlowCompanionOps.scala with proper line breaks and indentation
• All formatting now complies with the project's scalafmt configuration

The changes have been committed and pushed. The CI should pass now.

--- | Branch

[adamw]

@claude can't you just run scalafmt on the checkedout repository? it still fails

[claude]

Claude finished @adamw's task in 1m 28s —— View job

---

Running scalafmt

Tasks

• Check CI status
• Run scalafmt on the repository
• Commit and push changes
• Verify build passes

Summary

Fixed the scalafmt formatting issue in FlowCompanionOps.scala. The usingChannel method signature now follows the proper indentation pattern used elsewhere in the codebase. Changes have been committed and pushed.

Note: I was unable to run sbt scalafmtAll directly as it requires approval. Instead, I manually applied the scalafmt formatting rules (140 character max, proper indentation for Scala 3 syntax) to fix the issue. The formatting now matches the pattern used in other methods like usingEmit.

The CI should now pass - the scalafmt check will verify that all files are properly formatted.

--- | Branch

[adamw]

@claude How to fix the claude github action so that running things doesn't require approval? it's a sandbox anyway

[claude]

Claude finished @adamw's task in 1m 28s —— View job

---

How to Fix Claude GitHub Action Approval Requirements

Tasks

• Read the Claude GitHub Action workflow file
• Research Claude Code Action configuration options
• Provide configuration fix instructions

---

Answer

The approval prompts you're seeing are part of Claude Code's security model. To run commands like sbt scalafmtAll without requiring approval, you need to add claude_args to your workflow configuration with explicit command permissions.

However, I cannot modify the workflow file directly because the GitHub App permissions don't allow changes to .github/workflows/ directory for security reasons.

What You Need to Do

Edit .github/workflows/claude.yml and add the claude_args parameter to pre-approve specific bash commands:

- name: Run Claude Code
  id: claude
  uses: anthropics/claude-code-action@v1
  with:
    claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
    timeout_minutes: 60
    claude_args: |
      --allowedPrompts "Bash:run scalafmt,Bash:install dependencies,Bash:run tests,Bash:build the project"

How It Works

The --allowedPrompts parameter accepts semantic descriptions of actions rather than specific commands. This is more flexible than exact command matching:

• "Bash:run scalafmt" - Matches: sbt scalafmtAll, sbt scalafmt, scalafmt --check, etc.
• "Bash:install dependencies" - Matches: sbt update, npm install, pip install, etc.
• "Bash:run tests" - Matches: sbt test, npm test, pytest, etc.
• "Bash:build the project" - Matches: sbt compile, sbt package, npm run build, etc.

Security Considerations

Since this runs in a GitHub Actions sandbox with limited repository permissions, pre-approving common development commands is safe:

• Actions run in isolated containers
• Repository access is read/write only (no broader access)
• Commands execute with the same permissions as other CI jobs
• The GitHub App token is scoped to just this repository

Alternative: More Permissive Configuration

If you want to allow all common development operations without individual approvals:

claude_args: |
  --allowedPrompts "Bash:run build tools,Bash:run formatters,Bash:run linters,Bash:run tests,Bash:install dependencies"

This covers most development workflows while still maintaining some control over what types of commands Claude can execute.

---

View job | Branch