Increase max connections for postgres container, use smaller hikari pool

[mprins]

Increase max connections for the "postgres" container as it can run out of connections during integration tests, also use half of the default pool size to prevent exhausting the connections.

Applies:

• more available connections on the postgres container
• smaller hikari pool
  to prevent connection exhaust problems during integration testing.

A comprehensive write-up in https://stackoverflow.com/questions/79028148/hikari-pool-is-not-shutdown-after-spring-boot-test-execution-with-test-container

Worth reading: https://commerce-engineer.rakuten.careers/entry/en/tech/0054

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA ae8d0b0.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

None

[github-actions]

Test Results

479 tests   477 ✅  5m 53s ⏱️
 54 suites    1 💤
 54 files      1 ❌

For more details on these failures, see this check.

Results for commit ae8d0b0.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR adjusts PostgreSQL and Hikari connection limits to prevent connection exhaustion during integration testing.

Changes:

• Increase PostgreSQL max_connections in the CI docker-compose Postgres service.
• Reduce HikariCP maximum pool size in the PostgreSQL test profile properties.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/test/resources/application-postgresql.properties	Limits HikariCP pool size during PostgreSQL-backed tests to reduce concurrent DB connections.
build/ci/docker-compose.yml	Raises PostgreSQL server-side connection cap for the CI container.

[matthijsln]

Interesting. Can we use a strategic @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) somewhere to make it more robust?

[mprins]

Interesting. Can we use a strategic @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) somewhere to make it more robust?

maybe; but we would need to analyse the cached instances and I expect the testsuite would take more time: @DirtiesContext because the ApplicationContext needs to be reinitialised...

perhaps easier to specify spring.test.context.cache.maxSize (default 32) with a value that matches the pool.

Also see: Spring @DirtiesContext — false friend

[codecov]

❌ 1 Tests Failed:

Tests completed	Failed	Passed	Skipped
531	1	530	1

View the full list of 1 ❄️ flaky test(s)

org.tailormap.api.controller.admin.TaskAdminControllerIntegrationTest::details_of_task

Flake rate in main: 42.86% (Passed 16 times, Failed 12 times)

Stack Traces | 0.038s run time

Status expected:<200> but was:<500>

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[matthijsln]

Interesting. Can we use a strategic @DirtiesContext(classMode = DirtiesContext.ClassMode.AFTER_CLASS) somewhere to make it more robust?

maybe; but we would need to analyse the cached instances and I expect the testsuite would take more time: @DirtiesContext because the ApplicationContext needs to be reinitialised...

perhaps easier to specify spring.test.context.cache.maxSize (default 32) with a value that matches the pool.

Also see: Spring @DirtiesContext — false friend

Would indeed require analysis which tests create another context, but the point would be to add that annotation to a test that creates a new context anyway (hence increasing the number of database connections), which would not be reused. But the cache max size is probably easier!