Skip to content

Integrate JiT compilation into CLI runtime#2211

Open
rafal-hawrylak wants to merge 6 commits into
mainfrom
pr4c-jit-runtime
Open

Integrate JiT compilation into CLI runtime#2211
rafal-hawrylak wants to merge 6 commits into
mainfrom
pr4c-jit-runtime

Conversation

@rafal-hawrylak

Copy link
Copy Markdown
Collaborator

#2184 with extracted refactorings.

@rafal-hawrylak
rafal-hawrylak requested a review from a team as a code owner June 19, 2026 19:18
@rafal-hawrylak
rafal-hawrylak requested review from udim and removed request for a team June 19, 2026 19:18
@rafal-hawrylak

Copy link
Copy Markdown
Collaborator Author

Need to address: #2184 (comment)

@rafal-hawrylak

rafal-hawrylak commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator Author

Need to address: #2184 (comment)

Solved in:

Comment thread cli/api/commands/jit/compiler.ts Outdated
Comment thread cli/api/commands/base_worker.ts Outdated
Comment thread cli/api/commands/build.ts Outdated
Comment thread cli/api/commands/base_worker.ts Outdated
Comment thread cli/api/commands/run.ts Outdated
Comment thread cli/api/commands/run.ts Outdated
Comment thread cli/api/utils/constants.ts Outdated
- base_worker: drop redundant undefined guard around clearTimeout
  (clearTimeout(undefined) is a documented no-op). Restore
  runWorker's timeoutMillis to a required number and drop the
  conditional setTimeout — matches main's contract; the earlier
  loosening to number|undefined let JiT workers run without any
  timeout when --jit-timeout was omitted.
- jit/compiler.ts: default timeoutMillis to
  DEFAULT_COMPILATION_TIMEOUT_MILLIS at the .compile() entry point
  (mirrors CompileChildProcess.compile), so JiT workers always
  have a timeout even without --jit-timeout.
- build.ts: replace unsafe (action as any).jitCode cast with a
  narrowing "jitCode" in action check.
- run.ts: flatten the outer try/catch that only wrapped the JiT-compile
  try; the JiT-compile block already has its own try/catch. Extract the
  action.tableType -> dataform.TableType mapping into tableTypeEnum.
- constants.ts: revert DEFAULT_COMPILATION_TIMEOUT_MILLIS to 60000
  (main's value); the per-JiT timeout is configurable via
  --jit-timeout.
- compiler.ts: keep the Array.from(response) conversion (child.send
  uses JSON IPC by default, which serializes Uint8Array as
  {"0":n,...} and Buffer.from() rejects that) but add a comment
  documenting the constraint.
Each JiT compile registered a cancel handler on the Runner's EventEmitter
but never removed it once the compile finished. A run with N JiT actions
therefore accumulated N stale listeners and eventually tripped the default
MaxListenersExceededWarning threshold.

Register the handler through a local variable and remove it in a finally
block so successful and failed compiles both clean up. Also drops a stray
trailing-whitespace line from the dryRun compiledSql branch (comment #2).
@rafal-hawrylak
rafal-hawrylak requested review from apilaskowski and removed request for udim July 22, 2026 11:20
Comment thread cli/api/BUILD
@@ -1,6 +1,6 @@
load("//tools:ts_library.bzl", "ts_library")

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is linter happy with this order?

Comment thread testing/test.ts

export class Test {
public static readonly DEFAULT_TIMEOUT_MILLIS = 30000;
public static readonly DEFAULT_TIMEOUT_MILLIS = 300000;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just making sure. Is this intentional that all tests will have timeout of 5 minutes now?

Comment thread cli/api/commands/run.ts
actionResult.status = dataform.ActionResult.ExecutionStatus.FAILED;
actionResult.tasks.push({
status: dataform.TaskResult.ExecutionStatus.FAILED,
errorMessage: `JiT compilation error: ${e.message}`

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we use e?.message || String(e) instead? This is just in case error thrown does not have message field.

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.

3 participants