Add services to study-light profile, add depends on#618
Conversation
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: LE SAULNIER Kevin <kevin.lesaulnier.pro@gmail.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
Signed-off-by: BOUHOURS Antoine <antoine.bouhours@rte-france.com>
📝 WalkthroughWalkthroughThis pull request orchestrates a comprehensive Docker Compose infrastructure update: infrastructure services (RabbitMQ, Postgres, Elasticsearch, MinIO) gain healthchecks; application services across base, study, monitor, and dynamic-mapping configurations transition to wait for healthy upstream dependencies rather than simply started state; JVM heap and container memory allocations are reduced across dozens of services; and a new study-light deployment profile is introduced with dedicated environment configuration and compose file composition. ChangesHealth Checks and Service Dependencies
Study-Light Profile Composition
Documentation Updates
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docker-compose/study/docker-compose.study.yml (1)
280-302:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winVerify that UI gracefully handles missing backends or add services to
study-light.
gridstudy-appis now in thestudy-lightprofile, but several analysis and calculation servers remain outside it:geo-data-server,cgmes-gl-server,odre-server,security-analysis-server,sensitivity-analysis-server,shortcircuit-server,voltage-init-server, andtimeseries-server. If the UI exposes features that call these services, users will encounter errors rather than disabled menu items. Either confirm the light variant intentionally omits these features, or perform a functional smoke test to verify graceful degradation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose/study/docker-compose.study.yml` around lines 280 - 302, The UI container gridstudy-app was added to the study-light profile while backend services (geo-data-server, cgmes-gl-server, odre-server, security-analysis-server, sensitivity-analysis-server, shortcircuit-server, voltage-init-server, timeseries-server) remain outside that profile, which can cause runtime UI errors; either add the missing services to the study-light profile in docker-compose.study.yml so the light profile includes those backend services, or modify the UI (gridstudy-app) to detect and gracefully disable/hide features that call those specific services (check client-side code that references those service endpoints) and implement fallbacks/error-handling for absent backends. Ensure you update service profiles for each listed service or add feature-gating in the UI code paths that call endpoints for geo-data-server, cgmes-gl-server, odre-server, security-analysis-server, sensitivity-analysis-server, shortcircuit-server, voltage-init-server, and timeseries-server.
🧹 Nitpick comments (4)
docker-compose/technical/docker-compose.technical.yml (2)
9-13: ⚡ Quick winConsider adding
start_periodto healthchecks.The healthchecks have
retries: 10withinterval: 10s(≈100s tolerance), but nostart_period. During slow boots (e.g., Postgres runninginit-databases.shto bootstrap geo data / lines catalog, or Elasticsearch cluster bootstrap), early probe failures will count towardretries, which can flap dependent services that rely oncondition: service_healthy. Astart_period(e.g.,30s–60s) prevents early failures from being counted.🛠️ Example for postgres
healthcheck: test: ["CMD-SHELL", "pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DEFAULT_DB"] interval: 10s timeout: 5s retries: 10 + start_period: 30sAlso applies to: 51-55, 88-92, 192-196
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose/technical/docker-compose.technical.yml` around lines 9 - 13, The RabbitMQ healthcheck block (healthcheck with test: ["CMD-SHELL", "rabbitmq-diagnostics ping"]) currently uses interval and retries but no start_period, so add a start_period (e.g., start_period: 30s–60s) to that healthcheck so early boot failures aren’t counted toward retries; apply the same change to the other healthcheck blocks referenced (the ones using healthcheck, interval, timeout, retries) to ensure dependent services using condition: service_healthy don’t flap during slow initialization.
192-196: ⚡ Quick winUse
mc ready localfor the healthcheck probe.The current
curl-based healthcheck works (curl is present in the image), but MinIO's official guidance recommends["CMD", "mc", "ready", "local"]instead. This is more reliable as it directly checks local node readiness without depending on HTTP endpoints.Consider updating line 193 to:
test: ["CMD", "mc", "ready", "local"]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose/technical/docker-compose.technical.yml` around lines 192 - 196, The healthcheck currently uses a curl-based probe in the healthcheck.test block which relies on HTTP and is less reliable; replace the test command to use MinIO's CLI readiness check by switching the healthcheck.test from the curl invocation to use mc ready local (i.e., update the healthcheck.test entry to call ["CMD", "mc", "ready", "local"]); ensure the healthcheck section (healthcheck.test, interval, timeout, retries) remains intact and that the container image includes the mc binary so mc ready can run successfully.README.md (1)
96-113: 💤 Low valueProfile/service matrix is hard to scan — consider stable row ordering.
The table mixes per-row multi-service grouping with single-service rows, and the grouping criterion is the matching profile set. Two small polish items:
- The rows aren’t alphabetized within each grouping (e.g., line 108 lists
directory-notification-server<br>explore-server<br>gridexplore-app<br>...which is correct, but other rows like line 112 start withapps-metadata-server<br>case-server<br>...ordering — make sure ordering is consistent across rows so reviewers can diff quickly).- A
study-lightcolumn was added; consider adding a leading legend row (e.g., what(none)means vs blank cells in newly added profiles) so the asymmetry between(none)getting✅only on the infra row (line 113) and other rows being blank is explicit.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@README.md` around lines 96 - 113, The profile/service matrix is hard to scan because grouped cell lists are inconsistently ordered and the meaning of the “_(none)_” column vs blank cells is unclear; fix by alphabetizing service names within each multi-service row (e.g., rows containing directory-notification-server, explore-server, gridexplore-app, gridstudy-app, network-map-server, single-line-diagram-server, study-notification-server, study-server) to a stable lexical order and ensure all grouped rows follow the same ordering rule, and add a leading legend row above the table that explains the “_(none)_” column vs empty cells (and confirm the infra row with elasticsearch/postgres/rabbitmq/s3-storage retains the ✅ under “_(none)_” if that denotes required infra).docker-compose/docker-compose.base.yml (1)
317-321: 💤 Low valueQuote unit-suffixed memory limits to avoid YAML/Compose ambiguity.
memswap_limit: 1g,memory: 1g, and the new1280mvalues are written unquoted. Docker Compose accepts these, but mixing quoted ("512m") and unquoted forms across the same file is inconsistent and historically has bitten teams when a value like1g(with a trailing space, as on line 317/321) is parsed by older toolchains. Quoting them as strings ("1g","1280m") is the documented form and removes the trailing-space risk visible here.Docker Compose memswap_limit and deploy.resources.limits.memory accepted formats and trailing whitespace handlingAlso applies to: 354-358, 279-283
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker-compose/docker-compose.base.yml` around lines 317 - 321, Update the YAML to quote all unit-suffixed memory values to avoid parsing ambiguity: change occurrences of memswap_limit and deploy.resources.limits.memory (and any other memory keys like those at the other noted blocks) from unquoted forms such as 1g, 1280m or 512m to quoted strings like "1g" and "1280m", ensuring no trailing spaces remain inside the quotes; apply this to the memswap_limit and deploy.resources.limits.memory entries referenced in the diff and the other blocks called out.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docker-compose/docker-compose.base.yml`:
- Around line 377-381: The docker-compose.services for config-server and
config-notification-server unintentionally lost the optional logspout ordering
dependency; restore a depends_on entry mirroring other services by adding a
logspout: { condition: service_started, required: false } under the existing
depends_on block for both config-server and config-notification-server (look for
the depends_on: postgres/rabbitmq blocks in docker-compose.base.yml and add the
logspout entry similarly, and apply the same fix at the other occurrence
referenced around lines ~409-411).
- Around line 18-29: The depends_on entry for rabbitmq under the case-server
service is too strict; remove or relax it so case-server startup isn't blocked
by transient RabbitMQ issues: locate the depends_on block for the case-server
service (the rabbitmq sub-entry) and either remove the rabbitmq dependency
entirely, or change its condition from service_healthy to "service_started" and
add required: false; alternatively verify in case-server application config
(case-server-application.yml) and code that it actually binds to Spring Cloud
Stream at boot—if it does, keep the dependency but document why it's needed.
In `@docker-compose/study-light/.env`:
- Line 1: The env flag SHOULD_INIT_GEO_DATA is enabling geo-data initialization
even though the geo-data-server service is excluded from the study-light
profile; either set SHOULD_INIT_GEO_DATA=false in the study-light .env to
prevent Postgres from loading unused geo data, or add the geo-data-server
service to the study-light profile in your docker-compose study configuration so
the data loading is actually served; locate the SHOULD_INIT_GEO_DATA entry in
the study-light .env and the geo-data-server service definition/profile key
(profile "study-light") in the docker-compose study compose file to apply one of
these two fixes.
In `@docker-compose/study/docker-compose.study.yml`:
- Around line 350-356: The three services dynamic-simulation-server,
dynamic-security-analysis-server, and dynamic-margin-calculation-server dropped
the optional logspout ordering hint; restore a depends_on entry for logspout
with condition: service_started and required: false for each of these services
(i.e., add the same "logspout: { condition: service_started, required: false }"
block alongside the existing postgres/s3-storage/rabbitmq depends_on entries) so
their startup ordering matches the other study services.
In `@README.md`:
- Line 60: The in-page anchor in the sentence containing "profiles as explained
in the [next section](`#docker-compose-profiles`)" doesn't match the header text
"### Docker-compose with profiles"; update the link target to the correct anchor
`#docker-compose-with-profiles` (or alternatively rename the header to
"Docker-compose with profiles" -> "Docker-compose profiles" to match
`#docker-compose-profiles`) so the link points to the actual "Docker-compose
with profiles" section; locate the link text in README.md and adjust the anchor
or the header text accordingly.
---
Outside diff comments:
In `@docker-compose/study/docker-compose.study.yml`:
- Around line 280-302: The UI container gridstudy-app was added to the
study-light profile while backend services (geo-data-server, cgmes-gl-server,
odre-server, security-analysis-server, sensitivity-analysis-server,
shortcircuit-server, voltage-init-server, timeseries-server) remain outside that
profile, which can cause runtime UI errors; either add the missing services to
the study-light profile in docker-compose.study.yml so the light profile
includes those backend services, or modify the UI (gridstudy-app) to detect and
gracefully disable/hide features that call those specific services (check
client-side code that references those service endpoints) and implement
fallbacks/error-handling for absent backends. Ensure you update service profiles
for each listed service or add feature-gating in the UI code paths that call
endpoints for geo-data-server, cgmes-gl-server, odre-server,
security-analysis-server, sensitivity-analysis-server, shortcircuit-server,
voltage-init-server, and timeseries-server.
---
Nitpick comments:
In `@docker-compose/docker-compose.base.yml`:
- Around line 317-321: Update the YAML to quote all unit-suffixed memory values
to avoid parsing ambiguity: change occurrences of memswap_limit and
deploy.resources.limits.memory (and any other memory keys like those at the
other noted blocks) from unquoted forms such as 1g, 1280m or 512m to quoted
strings like "1g" and "1280m", ensuring no trailing spaces remain inside the
quotes; apply this to the memswap_limit and deploy.resources.limits.memory
entries referenced in the diff and the other blocks called out.
In `@docker-compose/technical/docker-compose.technical.yml`:
- Around line 9-13: The RabbitMQ healthcheck block (healthcheck with test:
["CMD-SHELL", "rabbitmq-diagnostics ping"]) currently uses interval and retries
but no start_period, so add a start_period (e.g., start_period: 30s–60s) to that
healthcheck so early boot failures aren’t counted toward retries; apply the same
change to the other healthcheck blocks referenced (the ones using healthcheck,
interval, timeout, retries) to ensure dependent services using condition:
service_healthy don’t flap during slow initialization.
- Around line 192-196: The healthcheck currently uses a curl-based probe in the
healthcheck.test block which relies on HTTP and is less reliable; replace the
test command to use MinIO's CLI readiness check by switching the
healthcheck.test from the curl invocation to use mc ready local (i.e., update
the healthcheck.test entry to call ["CMD", "mc", "ready", "local"]); ensure the
healthcheck section (healthcheck.test, interval, timeout, retries) remains
intact and that the container image includes the mc binary so mc ready can run
successfully.
In `@README.md`:
- Around line 96-113: The profile/service matrix is hard to scan because grouped
cell lists are inconsistently ordered and the meaning of the “_(none)_” column
vs blank cells is unclear; fix by alphabetizing service names within each
multi-service row (e.g., rows containing directory-notification-server,
explore-server, gridexplore-app, gridstudy-app, network-map-server,
single-line-diagram-server, study-notification-server, study-server) to a stable
lexical order and ensure all grouped rows follow the same ordering rule, and add
a leading legend row above the table that explains the “_(none)_” column vs
empty cells (and confirm the infra row with
elasticsearch/postgres/rabbitmq/s3-storage retains the ✅ under “_(none)_” if
that denotes required infra).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e7a6c336-64ae-4296-bc3d-30b31869cd6e
📒 Files selected for processing (8)
README.mddocker-compose/docker-compose.base.ymldocker-compose/dynamic-mapping/docker-compose.dynamic-mapping.ymldocker-compose/monitor/docker-compose.monitor.ymldocker-compose/study-light/.envdocker-compose/study-light/docker-compose.ymldocker-compose/study/docker-compose.study.ymldocker-compose/technical/docker-compose.technical.yml
| depends_on: | ||
| postgres: | ||
| condition: service_healthy | ||
| elasticsearch: | ||
| condition: service_healthy | ||
| s3-storage: | ||
| condition: service_healthy | ||
| rabbitmq: | ||
| condition: service_healthy | ||
| logspout: | ||
| condition: "service_started" | ||
| required: false |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
fd -t f 'case-server-application.ya?ml$' -X rg -n -C2 -i 'rabbit|amqp|spring\.cloud\.stream'Repository: gridsuite/deployment
Length of output: 46
🏁 Script executed:
#!/bin/bash
# First, let's find the docker-compose file mentioned in the review
find . -name "docker-compose.base.yml" -type fRepository: gridsuite/deployment
Length of output: 105
🏁 Script executed:
#!/bin/bash
# Look for case-server related files in the repository
fd -t f 'case' | grep -E '(config|application|properties|yaml|yml)' | head -20Repository: gridsuite/deployment
Length of output: 626
🏁 Script executed:
#!/bin/bash
# Check the docker-compose.base.yml file to understand context
cat docker-compose/docker-compose.base.yml | head -40Repository: gridsuite/deployment
Length of output: 1133
🏁 Script executed:
#!/bin/bash
# Search for case-server service definition and its depends_on configuration
rg -A 10 "case-server:" docker-compose/ --type yamlRepository: gridsuite/deployment
Length of output: 1452
🏁 Script executed:
#!/bin/bash
# Read the case-server-application.yml file
cat k8s/resources/common/config/case-server-application.ymlRepository: gridsuite/deployment
Length of output: 46
🏁 Script executed:
#!/bin/bash
# Also check the common-application.yml to see if rabbitmq is configured there
cat k8s/resources/common/config/common-application.yml | head -100Repository: gridsuite/deployment
Length of output: 921
🏁 Script executed:
#!/bin/bash
# Search for any rabbitmq or amqp configuration across the k8s config directory
rg -i 'rabbit|amqp|spring\.cloud\.stream' k8s/resources/common/config/Repository: gridsuite/deployment
Length of output: 463
🏁 Script executed:
#!/bin/bash
# Check the size and content of case-server-application.yml
wc -l k8s/resources/common/config/case-server-application.yml
cat -n k8s/resources/common/config/case-server-application.ymlRepository: gridsuite/deployment
Length of output: 122
🏁 Script executed:
#!/bin/bash
# Search for spring.cloud.stream bindings in case-server config
rg -i 'spring\.cloud\.stream|binding' k8s/resources/common/config/case-server-application.ymlRepository: gridsuite/deployment
Length of output: 46
🏁 Script executed:
#!/bin/bash
# Check which services in docker-compose depend on rabbitmq
rg -B5 'condition: service_healthy' docker-compose/docker-compose.base.yml | grep -E '(^\s+[a-z-]+:|rabbitmq)'Repository: gridsuite/deployment
Length of output: 1485
🏁 Script executed:
#!/antml/bash
# List all services and their rabbitmq dependencies
rg 'rabbitmq:' -B20 docker-compose/ --type yaml | rg -E '^\s+[a-z-]+:|rabbitmq:'Repository: gridsuite/deployment
Length of output: 461
🏁 Script executed:
#!/bin/bash
# Get all services from docker-compose and their rabbitmq dependency status
rg -A 30 '^\s+[a-z-]+:\s*$' docker-compose/docker-compose.base.yml | rg -E '^\s+[a-z-]+:\s*$|rabbitmq:'Repository: gridsuite/deployment
Length of output: 461
🏁 Script executed:
#!/bin/bash
# Check which other service configs mention spring.cloud.stream or rabbitmq bindings
find k8s/resources/common/config -name '*application.yml' -type fRepository: gridsuite/deployment
Length of output: 993
🏁 Script executed:
#!/bin/bash
# Check if there are service-specific spring.cloud.stream configurations
for file in $(find k8s/resources/common/config -name '*application.yml' -type f); do
echo "=== $file ==="
rg -i 'spring\.cloud\.stream|binding' "$file" || echo "No spring.cloud.stream"
doneRepository: gridsuite/deployment
Length of output: 1477
🏁 Script executed:
#!/bin/bash
# Check the case-import-server config since it also depends on rabbitmq
cat k8s/resources/common/config/case-import-server-application.ymlRepository: gridsuite/deployment
Length of output: 46
🏁 Script executed:
#!/bin/bash
# Get full docker-compose to identify which services actually use rabbitmq
grep -n "rabbitmq:" docker-compose/docker-compose.base.yml | head -20Repository: gridsuite/deployment
Length of output: 222
🏁 Script executed:
#!/bin/bash
# Check services that depend on rabbitmq - identify which ones actually need it
awk '/depends_on:/,/restart:/' docker-compose/docker-compose.base.yml | grep -B 20 'rabbitmq:' | grep -E '^\s+[a-z-]+:|rabbitmq:'Repository: gridsuite/deployment
Length of output: 1607
Remove or reconsider the rabbitmq: service_healthy dependency for case-server.
case-server is primarily a case storage service proxying S3 + Postgres + Elasticsearch. The hard dependency on RabbitMQ at startup is questionable: no spring.cloud.stream bindings are configured in case-server-application.yml (which is empty), and RabbitMQ is not on the documented startup critical path. A transient RabbitMQ outage will unnecessarily block case-server startup. Either remove this dependency entirely, change it to service_started with required: false, or confirm that case-server actually publishes/consumes messages at boot rather than lazily.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/docker-compose.base.yml` around lines 18 - 29, The depends_on
entry for rabbitmq under the case-server service is too strict; remove or relax
it so case-server startup isn't blocked by transient RabbitMQ issues: locate the
depends_on block for the case-server service (the rabbitmq sub-entry) and either
remove the rabbitmq dependency entirely, or change its condition from
service_healthy to "service_started" and add required: false; alternatively
verify in case-server application config (case-server-application.yml) and code
that it actually binds to Spring Cloud Stream at boot—if it does, keep the
dependency but document why it's needed.
| depends_on: | ||
| postgres: | ||
| condition: service_healthy | ||
| rabbitmq: | ||
| condition: service_healthy |
There was a problem hiding this comment.
logspout depends_on entry was dropped for config-server and config-notification-server.
Every other service in this file retains the optional logspout: service_started (with required: false) ordering hint, but it’s gone here. Given the PR description states the intent is to add missing depends_on entries (not remove them), this looks unintentional and will make these two containers skip the logspout start ordering when the kibana/all profile is active.
🔧 Restore logspout ordering
depends_on:
postgres:
condition: service_healthy
rabbitmq:
condition: service_healthy
+ logspout:
+ condition: "service_started"
+ required: false(apply analogously to config-notification-server)
Also applies to: 409-411
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/docker-compose.base.yml` around lines 377 - 381, The
docker-compose.services for config-server and config-notification-server
unintentionally lost the optional logspout ordering dependency; restore a
depends_on entry mirroring other services by adding a logspout: { condition:
service_started, required: false } under the existing depends_on block for both
config-server and config-notification-server (look for the depends_on:
postgres/rabbitmq blocks in docker-compose.base.yml and add the logspout entry
similarly, and apply the same fix at the other occurrence referenced around
lines ~409-411).
| @@ -0,0 +1,5 @@ | |||
| SHOULD_INIT_GEO_DATA=true | |||
There was a problem hiding this comment.
Setting SHOULD_INIT_GEO_DATA=true while geo-data-server is not in the study-light profile is wasteful.
geo-data-server is excluded from study-light in docker-compose/study/docker-compose.study.yml, but this .env still triggers the geo-data initialization at Postgres boot. The data will be loaded into Postgres but never served — pure I/O / disk cost on a profile whose purpose is to reduce footprint. Either set this to false for study-light, or include geo-data-server in the profile if map features are intended.
🔧 Drop geo-data init from study-light
-SHOULD_INIT_GEO_DATA=true
+SHOULD_INIT_GEO_DATA=false
SHOULD_INIT_LINES_CATALOG=true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| SHOULD_INIT_GEO_DATA=true | |
| SHOULD_INIT_GEO_DATA=false |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/study-light/.env` at line 1, The env flag SHOULD_INIT_GEO_DATA
is enabling geo-data initialization even though the geo-data-server service is
excluded from the study-light profile; either set SHOULD_INIT_GEO_DATA=false in
the study-light .env to prevent Postgres from loading unused geo data, or add
the geo-data-server service to the study-light profile in your docker-compose
study configuration so the data loading is actually served; locate the
SHOULD_INIT_GEO_DATA entry in the study-light .env and the geo-data-server
service definition/profile key (profile "study-light") in the docker-compose
study compose file to apply one of these two fixes.
| depends_on: | ||
| postgres: | ||
| condition: service_healthy | ||
| s3-storage: | ||
| condition: service_healthy | ||
| rabbitmq: | ||
| condition: service_healthy |
There was a problem hiding this comment.
logspout dependency was dropped from the dynamic- servers.*
dynamic-simulation-server, dynamic-security-analysis-server, and dynamic-margin-calculation-server now declare only the healthy infra dependencies under depends_on: — the previous optional logspout: service_started (required: false) ordering hint is gone. Other study services in this same file kept it. Likely an unintended omission given the PR description’s "add missing depends-on entries" intent.
🔧 Restore logspout ordering on each of the three services
depends_on:
postgres:
condition: service_healthy
s3-storage:
condition: service_healthy
rabbitmq:
condition: service_healthy
+ logspout:
+ condition: "service_started"
+ required: falseAlso applies to: 381-387, 412-418
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docker-compose/study/docker-compose.study.yml` around lines 350 - 356, The
three services dynamic-simulation-server, dynamic-security-analysis-server, and
dynamic-margin-calculation-server dropped the optional logspout ordering hint;
restore a depends_on entry for logspout with condition: service_started and
required: false for each of these services (i.e., add the same "logspout: {
condition: service_started, required: false }" block alongside the existing
postgres/s3-storage/rabbitmq depends_on entries) so their startup ordering
matches the other study services.
| ### Application profiles _(alias)_ | ||
| > [!NOTE] | ||
| > If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`), you have to use profiles as explained in the [next section](#docker-compose-profiles). | ||
| > If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`, `study-light`), you have to use profiles as explained in the [next section](#docker-compose-profiles). |
There was a problem hiding this comment.
Broken in-page anchor #docker-compose-profiles.
The link targets #docker-compose-profiles, but the section header at line 92 is ### Docker-compose with profiles, which GitHub renders as the anchor #docker-compose-with-profiles. As written, the link will scroll to the top of the README.
🔧 Fix the anchor
-> If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`, `study-light`), you have to use profiles as explained in the [next section](`#docker-compose-profiles`).
+> If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`, `study-light`), you have to use profiles as explained in the [next section](`#docker-compose-with-profiles`).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| > If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`, `study-light`), you have to use profiles as explained in the [next section](#docker-compose-profiles). | |
| > If you want to use profiles other than the ones associated with the folders (`dynamic-mapping`, `monitor`, `study`, `suite`, `technical`, `study-light`), you have to use profiles as explained in the [next section](`#docker-compose-with-profiles`). |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 60-60: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 60, The in-page anchor in the sentence containing
"profiles as explained in the [next section](`#docker-compose-profiles`)" doesn't
match the header text "### Docker-compose with profiles"; update the link target
to the correct anchor `#docker-compose-with-profiles` (or alternatively rename
the header to "Docker-compose with profiles" -> "Docker-compose profiles" to
match `#docker-compose-profiles`) so the link points to the actual
"Docker-compose with profiles" section; locate the link text in README.md and
adjust the anchor or the header text accordingly.
2 participants
PR Summary