Grails Domain Save Appears Successful but No Data Persists – Diagnostic Guide

Recognizable Condition

A POST request to a Grails controller or a direct service call returns a success status, the save() method returns a domain instance (not null), and no exception is thrown. Yet when you query the database the row is either unchanged or missing entirely. The user sees no validation feedback in the UI or logs.

Cause and Diagnostic Overview

Symptom	Likely Cause	What to Look For
Save returns instance, no error, DB unchanged	Validation errors silently swallowed by save() (no failOnError)	Domain instance has non‑empty errors collection after validate()
Save returns instance, DB unchanged, null values in columns	Data binding did not populate a property (bindable false or missing from whitelist)	Property value is null despite being present in request params
Save returns instance, DB unchanged, version column unchanged	Optimistic locking version mismatch; Hibernate discards the update	Domain instance’s version does not match the row’s version in DB
Save returns instance, DB unchanged, no SQL issued	Service method lacks transactional boundary; flush never occurs	Hibernate session is not flushed or is in FlushMode.MANUAL without explicit flush

Ordered Checks

1. Check validation silently.
   1. Load the domain instance in the Grails console (grails console) or a unit test.
   2. Set its properties exactly as they would be bound from the request (use a map or command object).
   3. Call domain.validate() and inspect domain.errors.
   4. If errors exist, re‑run domain.save(failOnError: true) to surface the constraint violation as an exception.

   Where to run: Grails console or any test class with @IntegrationTest. Permissions: none beyond normal app access. Placeholder: def instance = new Book(title: params.title, author: params.author). Expected check: instance.errors.hasErrors() is true. Risk: none; this is read‑only.

2. Verify data binding configuration.
   1. In the controller or service, log the raw request params (params) and the bound instance before save().
   2. Confirm each property you expect to be set has bindable = true in the domain class or is included in the whitelist (bindable or static constraints = { ... bindable true }).
   3. If a property is missing, add bindable true or adjust the whitelist.

   Where to run: In the controller action or service method (add temporary log.debug"Params: ${params}" and log.debug"Instance: ${instance}"). Permissions: ability to modify source and redeploy. Placeholder: class Book { static constraints = { title bindable: true author bindable: true } }. Expected check: After binding, instance.title equals the value from params.title. Risk: exposing params in logs; remove after debugging.

3. Confirm transactional boundaries and flush mode.
   1. Check the service method: it should be annotated with @Transactional (Grails 5) or grails.gorm.transactions.Transactional (Grails 6) or wrapped in withTransaction { … }.
   2. If you need immediate visibility (e.g., for a subsequent query in the same request), add flush: true to the save call or call domain.save(flush: true).
   3. Inspect Hibernate session flush mode: enable debug logging for org.hibernate.SQL and org.grails.orm to see whether an INSERT/UPDATE statement is issued and whether a commit follows.

   Where to run: In application.yml or logback.groovy set logger org.hibernate.SQL = DEBUG and logger org.grails.orm = DEBUG. Permissions: ability to change logging config and restart. Placeholder: @Transactional BookService.saveBook(Book book) { book.save(flush: true) }. Expected check: Log shows SQL statement and a commit; no "no transaction" warnings. Risk: increased log volume; revert after debugging.

Fixes Tied to Findings

• Validation errors: Change save() to save(failOnError: true) or explicitly return domain.errors to the caller so the UI can display messages.
• Binding problems: Ensure each domain property intended for mass assignment has bindable: true (or add it to the whitelist). Provide default values or make nullable columns accept null if appropriate.
• Optimistic locking: If concurrent updates are expected, either retrieve the latest version before saving (Book.get(id)) or handle org.springframework.dao.OptimisticLockingFailureException and retry.
• Missing transaction/flush: Annotate the service method with @Transactional (or grails.gorm.transactions.Transactional) and use save(flush: true) when you need the write to be visible before the request ends.

Escalation Criteria

• Repeated optimistic locking failures under load, indicating a design that cannot sustain the update frequency.
• Validation errors originating from database‑level constraints (unique indexes, check constraints) that are not captured by GORM validation.
• Suspected second‑level cache returning stale reads after a successful save; verify by disabling cache temporarily or using evict to force a DB read.

Practical Verification

After applying a fix, repeat the original request and:

1. Check the response for any validation messages (if applicable).
2. Query the database directly (SELECT * FROM book WHERE id = ?) to confirm the row reflects the expected values.
3. Ensure no new warnings appear in the org.hibernate.SQL or org.grails.orm logs.

If the row persists correctly and no errors are logged, the issue is resolved. Otherwise, return to the ordered checks and verify the next potential cause.