8839075805
Implements Phases 1-8 of the TFTSR implementation plan. Rust backend (Tauri 2.x, src-tauri/): - Multi-provider AI: OpenAI-compatible, Anthropic, Gemini, Mistral, Ollama - PII detection engine: 11 regex patterns with overlap resolution - SQLCipher AES-256 encrypted database with 10 versioned migrations - 28 Tauri IPC commands for triage, analysis, document, and system ops - Ollama: hardware probe, model recommendations, pull/delete with events - RCA and blameless post-mortem Markdown document generators - PDF export via printpdf - Audit log: SHA-256 hash of every external data send - Integration stubs for Confluence, ServiceNow, Azure DevOps (v0.2) Frontend (React 18 + TypeScript + Vite, src/): - 9 pages: full triage workflow NewIssue→LogUpload→Triage→Resolution→RCA→Postmortem→History+Settings - 7 components: ChatWindow, TriageProgress, PiiDiffViewer, DocEditor, HardwareReport, ModelSelector, UI primitives - 3 Zustand stores: session, settings (persisted), history - Type-safe tauriCommands.ts matching Rust backend types exactly - 8 IT domain system prompts (Linux, Windows, Network, K8s, DB, Virt, HW, Obs) DevOps: - .woodpecker/test.yml: rustfmt, clippy, cargo test, tsc, vitest on every push - .woodpecker/release.yml: linux/amd64 + linux/arm64 builds, Gogs release upload Verified: - cargo check: zero errors - tsc --noEmit: zero errors - vitest run: 13/13 unit tests passing Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
75 lines
2.4 KiB
Markdown
75 lines
2.4 KiB
Markdown
# signal-exit
|
|
|
|
When you want to fire an event no matter how a process exits:
|
|
|
|
- reaching the end of execution.
|
|
- explicitly having `process.exit(code)` called.
|
|
- having `process.kill(pid, sig)` called.
|
|
- receiving a fatal signal from outside the process
|
|
|
|
Use `signal-exit`.
|
|
|
|
```js
|
|
// Hybrid module, either works
|
|
import { onExit } from 'signal-exit'
|
|
// or:
|
|
// const { onExit } = require('signal-exit')
|
|
|
|
onExit((code, signal) => {
|
|
console.log('process exited!', code, signal)
|
|
})
|
|
```
|
|
|
|
## API
|
|
|
|
`remove = onExit((code, signal) => {}, options)`
|
|
|
|
The return value of the function is a function that will remove
|
|
the handler.
|
|
|
|
Note that the function _only_ fires for signals if the signal
|
|
would cause the process to exit. That is, there are no other
|
|
listeners, and it is a fatal signal.
|
|
|
|
If the global `process` object is not suitable for this purpose
|
|
(ie, it's unset, or doesn't have an `emit` method, etc.) then the
|
|
`onExit` function is a no-op that returns a no-op `remove` method.
|
|
|
|
### Options
|
|
|
|
- `alwaysLast`: Run this handler after any other signal or exit
|
|
handlers. This causes `process.emit` to be monkeypatched.
|
|
|
|
### Capturing Signal Exits
|
|
|
|
If the handler returns an exact boolean `true`, and the exit is a
|
|
due to signal, then the signal will be considered handled, and
|
|
will _not_ trigger a synthetic `process.kill(process.pid,
|
|
signal)` after firing the `onExit` handlers.
|
|
|
|
In this case, it your responsibility as the caller to exit with a
|
|
signal (for example, by calling `process.kill()`) if you wish to
|
|
preserve the same exit status that would otherwise have occurred.
|
|
If you do not, then the process will likely exit gracefully with
|
|
status 0 at some point, assuming that no other terminating signal
|
|
or other exit trigger occurs.
|
|
|
|
Prior to calling handlers, the `onExit` machinery is unloaded, so
|
|
any subsequent exits or signals will not be handled, even if the
|
|
signal is captured and the exit is thus prevented.
|
|
|
|
Note that numeric code exits may indicate that the process is
|
|
already committed to exiting, for example due to a fatal
|
|
exception or unhandled promise rejection, and so there is no way to
|
|
prevent it safely.
|
|
|
|
### Browser Fallback
|
|
|
|
The `'signal-exit/browser'` module is the same fallback shim that
|
|
just doesn't do anything, but presents the same function
|
|
interface.
|
|
|
|
Patches welcome to add something that hooks onto
|
|
`window.onbeforeunload` or similar, but it might just not be a
|
|
thing that makes sense there.
|