k6 teardown rollback gap after schema changes under forced termination

k6's documented execution lifecycle includes a teardown() function that runs after all VUs finish. That makes teardown a natural place to drop temporary schema objects or restore a prior schema state when a load test creates database artifacts.

The uncertainty is what happens when the test process does not stop gracefully. Normal SIGINT/SIGTERM handling is documented to finish the current iteration and then run teardown, but an abrupt kill (SIGKILL) prevents k6 from receiving the signal. The documentation does not appear to guarantee teardown for every abnormal termination path, and behavior may differ in older k6 releases before v0.45.

For a test environment where schema changes must be rolled back safely, relying only on teardown leaves an unresolved design decision. Should rollback be idempotent and external to k6, or is there a supported lifecycle hook that covers forced termination?

• Does k6 guarantee teardown execution after a graceful stop across supported versions?
• What teardown behavior is documented, if any, when the k6 process is killed abruptly?
• How should schema rollback be structured when teardown may not run?