The GitHub Actions job "CI" on grails-core.git/build/neo4j-groovy4-baseline has 
succeeded.
Run started by GitHub user borinquenkid (triggered by borinquenkid).

Head commit for run:
c0246581814452ee09804d7024491da9caf490a4 / Walter Duque de Estrada 
<[email protected]>
fix: resolve Neo4j regressions surfaced by rebasing onto Groovy 5

Rebasing build/neo4j-groovy4-baseline onto current 8.0.x (which has moved
to Groovy 5.0.7) surfaced 18 failing tests beyond the baseline migration's
own known-pending set. Root-caused and fixed the following:

- Bump grails-data-neo4j's own groovyVersion/spockVersion to 5.0.7 /
  2.4-groovy-5.0 to match what the rest of 8.0.x now resolves; the module's
  properties were stale at 4.0.32, causing Spock to refuse to run entirely.
- Neo4jQuery: widen the to-one association id-collection condition so a
  mandatory (non-nullable), lazy to-one also has its real id collected,
  fixing <property>Id lookups that were silently returning the parent's id
  instead (OneToOneSpec); add IS NULL fallbacks for the NOT_EQUALS and
  EQUALS(null) comparison operators, matching GORM's non-SQL-null-semantics
  expectations for countByXNotEqual and findWhere/findAllWhere(prop: null).
- Neo4jGormStaticApi: add the missing narrowing cast the stricter Groovy 5
  compiler now requires for executeUpdate's long-to-Integer return.
- GormValidationApi (grails-datamapping-core): getValidator() permanently
  cached the first auto-discovered validator instead of re-resolving from
  the MappingContext on each call - harmless for adapters that build a
  fresh datastore per test, but silently ignored every later test's
  registered mock validator for adapters (Neo4j) that reuse one datastore
  across a whole spec class. Re-resolve on every call unless explicitly
  overridden via setValidator().
- WithTransactionSpec (grails-datamapping-tck): wrap the three
  withNewTransaction rollback scenarios in a fresh thread - Neo4j has no
  ambient-session nested-transaction support, so running on the same
  thread as the TCK harness's own per-test transaction silently bypassed
  the rollback under test; a fresh thread has no ambient session, matching
  the workaround the module's own legacy WithTransactionSpec already used.
- Two legacy grails.gorm.tests specs (OneToOneSpec, OneToManyUpdateSpec)
  had assertions written against the very bugs fixed above (asserting a
  DataIntegrityViolationException / a swapped id as "expected" behavior);
  updated both to assert the now-correct behavior.

Remaining known-accepted failures (pre-existing, not caused by this rebase):
OneToManySpec (a inverse-collection-timing fix attempt caused a worse
regression in AssignedIdSpec and was reverted), OptimisticLockingSpec and
FindWhereSpec (confirmed Neo4j-adapter-specific via H5/H7/Mongo all passing
the identical shared TCK tests), plus 3 tests that now pass under
@PendingFeatureIf but still report as such due to an unresolved Spock
condition-evaluation timing quirk.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

Report URL: https://github.com/apache/grails-core/actions/runs/28723236554

With regards,
GitHub Actions via GitBox

Reply via email to