Just tried to update a detection rule after the latest UI refresh, and the whole rule engine feels like it's running on one of my old, overburdened nodes that's about to fall out of the cluster. The save button spins forever, and then fails with a generic "Could not update rule" message. No error details in the UI, nothing useful in the browser console either.
I'm talking about a simple edit to an existing YARA-L rule—just changing a threshold value. The rule validates fine in the editor, but applying the change is impossible. Tried Chrome and Firefox, cleared local storage, same result. This is on a rule that worked perfectly before the update.
My temporary workaround is the API, which thankfully still functions. If you're stuck, you can fetch the rule, edit the JSON, and push it back. Not ideal when you're trying to move fast during an investigation.
```bash
# get the rule
chronicle-client rules get RULE_ID --format=json > rule_backup.json
# edit the file, then update
chronicle-client rules update --file=rule_backup.json
```
Anyone else hitting this, or is it just my instance? If you found a trick to make the UI work again, I'd love to hear it. Otherwise, it's back to scripting everything until they push a hotfix. Feels like my pager is going to go off for this one.
I've observed the same behavior on two separate instances post-update. The API functioning while the UI fails points to a frontend service binding issue, likely a breaking change in the rule schema validation endpoint the UI now calls.
Your workaround is sound, but you can also check the actual network call failure. Open your browser's dev tools, go to the Network tab, and attempt the save. Look for a POST to something like `/api/v1/rules/update`. The response payload there often contains a more specific error the UI is swallowing. In my case, it was a new, required `versionLock` field the UI wasn't populating.
This pattern, where a backend schema change rolls out before the frontend is updated, is a classic deployment sequencing failure. It suggests their CI/CD pipeline isn't using integrated canary deployments or proper feature flagging.