Configuration reference
All configuration keys are under the quarkus.goblin prefix.
In dev mode, once the Dev UI (or JSON-RPC) has changed the configuration, it is saved to .goblin-state.json in the project directory, and at the next start that file is loaded instead of the quarkus.goblin.assault.* keys and quarkus.goblin.target.level: editing those properties then has no effect until you delete the file. quarkus.goblin.enabled, quarkus.goblin.test.enabled and the build-time targeting rules are never taken from the file. In test mode the file is ignored.
|
The chaos layers are not configuration keys: every application starts with HTTP_IN and HTTP_OUT armed, and the layers are armed at runtime from the Dev UI or through JSON-RPC (applyConfig with a layers array); in dev mode the choice is persisted in .goblin-state.json. DATABASE requires a JDBC datasource and MESSAGING requires quarkus-messaging.
|
Every key is read at runtime and can be overridden when the application starts (environment variable, system
property, profile), except the three quarkus.goblin.target.include-packages / exclude-packages /
exclude-annotations targeting rules: they decide at build time which beans receive the service and messaging
interceptors, so they are fixed at build time (a dev-mode live reload rebuilds the application and picks them up).
| Key | Type | Default | Description |
|---|---|---|---|
|
|
|
Enable/disable the Goblin extension. Takes effect in dev mode, and in test mode together with |
|
|
|
Whether chaos is active in test mode ( |
|
|
|
Initial assault type enabled at startup. Values: |
|
|
|
Predefined composite assault mode. Values: |
|
|
|
Minimum latency in milliseconds. Must be lower than or equal to max-milliseconds; inverted values are swapped with a |
|
|
|
Maximum latency in milliseconds |
|
|
|
Fully qualified exception class name. Must extend |
|
|
|
Exception message |
|
|
|
HTTP status code to return. Must be in the |
|
|
|
HTTP response body |
|
|
|
Response body transformation to apply. Values: |
|
|
|
Target size of the transformed body in percent of the original, rounded down ( |
|
|
|
Action applied to the |
|
|
empty |
Header value written by the |
|
|
|
Percentage of requests to affect (0-100; values are clamped with a |
|
|
empty |
Package prefixes to include (empty = all packages). Fixed at build time. |
|
|
empty |
Package prefixes to exclude from chaos; an exclusion always wins over an inclusion. Fixed at build time. |
|
|
empty |
Exclude methods/classes carrying these annotations, on the |
Configuration validation
Goblin validates assault parameters at startup and whenever a change reaches the engine (Dev UI, JSON-RPC, import). Invalid values are never applied: Goblin logs a clear message and applies a safe fallback, so a misconfiguration cannot silently corrupt your chaos experiments.
Parameter |
Rule |
What happens |
|
|
Out-of-range values are clamped, inverted values are swapped, and a |
|
Must be in the |
Defaults to |
|
Class must exist, extend |
Falls back to |
|
Must be in |
Clamped to the valid range and a |
|
Must be in the |
Clamped and a |
At startup the checks run in AssaultEngine.onStart() and cover both the application.properties configuration and the state loaded from .goblin-state.json. The Dev UI validates the forms before saving: the Save button stays disabled while a value is invalid (for example a latency min greater than max), so these server-side corrections only apply to values that reach the engine another way — application.properties, JSON-RPC, an import or the state file. A value the forms accept but the engine corrects (a latency above 300000 ms, or an exception class that cannot be loaded, for instance) is corrected, persisted back to .goblin-state.json, and reported in a warning toast.