If you write a requestctl object with a YAML error, such as...

cidrs: [192.168.0.0/24, 2001:db8::/32]

(Did you spot it? The IPv4 range is fine, but the v6 range needs quotation marks, because in YAML the colon is significant!)

... and then proceed to run requestctl sync, it exits silently with status 0. It doesn't print the name of the object, which it would on syncing successfully -- but that's helpful only if you know to pay attention for it.

Better would be to print out the name of the file that didn't parse, possibly along with the error information from the YAML parser. This should probably be a warning rather than an error, because any other files will have synced successfully -- if somebody else left the malformed file lying around before you got there, you're still able to sync unrelated changes. Similarly it should probably still be an exit status of 0 (although I'm open to discussing that).