fix: add null safety for getDatastoreForConnection in data service factory bean

[jamesfredley]

Summary

• Add null guards after getDatastoreForConnection() calls in DatastoreServiceMethodInvokingFactoryBean.resolveEffectiveDatastore(), throwing a clear ConfigurationException with the connection name, domain class, and service class rather than silently setting a null datastore.
• Covers both the explicit @Transactional(connection=...) path and the domain class mapping inheritance path.

The MultipleConnectionSourceCapableDatastore interface doesn't guarantee non-null returns, and some implementations (e.g. Neo4j, SimpleMapDatastore) do a raw map lookup without validation. Hibernate already throws on missing connections, but this makes the factory bean defensive regardless of the underlying datastore implementation.

Flagged by Copilot review on #15472.

Tests

Added DatastoreServiceMethodInvokingFactoryBeanSpec with 7 Spock tests covering all resolveEffectiveDatastore() code paths:

Test	Path Covered
Non-multi-connection datastore passthrough	Early return for simple datastores
Default connection resolution	No annotation, no domain mapping
@Transactional(connection) resolution	Annotation-driven connection lookup
@Transactional(connection) null guard	ConfigurationException when connection missing
Domain class mapping resolution	Domain datasource mapping lookup
Domain class mapping null guard	ConfigurationException when connection missing
DEFAULT connection name passthrough	Annotation with DEFAULT does not override

Functional tests in grails-test-examples were assessed but are not feasible for this change - the null guard paths trigger ConfigurationException during bean initialization, which prevents application startup and cannot be caught in a running functional test.

[Copilot]

Pull request overview

This PR makes DatastoreServiceMethodInvokingFactoryBean.resolveEffectiveDatastore() defensive against MultipleConnectionSourceCapableDatastore.getDatastoreForConnection(...) returning null, by throwing a ConfigurationException instead of allowing a null datastore to be set on a data service.

Changes:

• Add null-guards after getDatastoreForConnection(...) for explicit @Transactional(connection=...) selection.
• Add null-guards after getDatastoreForConnection(...) for domain-class mapping-derived connection selection.
• Introduce ConfigurationException error messages intended to provide clearer misconfiguration diagnostics.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jdaugherty]

add tests?

[jamesfredley]

Added unit tests in DatastoreServiceMethodInvokingFactoryBeanSpec - 7 Spock tests covering all resolveEffectiveDatastore() code paths, including both null guard branches.

Regarding functional tests in grails-test-examples: these aren't feasible for this change. The null guard paths throw ConfigurationException during bean initialization (before the app is fully started), so there's no way to exercise them from a running functional test. The unit tests cover this thoroughly by mocking MultipleConnectionSourceCapableDatastore and verifying both the happy path and the error paths directly.