Yicong-Huang commented on code in PR #6858:
URL: https://github.com/apache/texera/pull/6858#discussion_r3741164740
##########
common/config/src/main/resources/application.conf:
##########
@@ -90,7 +90,7 @@ web-server {
clean-all-execution-results-on-server-start = false
clean-all-execution-results-on-server-start =
${?WEB_SERVER_CLEAN_ALL_EXECUTION_RESULTS_ON_SERVER_START}
- max-workflow-websocket-request-payload-size-kb = 64
+ max-workflow-websocket-request-payload-size-kb = 1024
Review Comment:
The default moved but its guard test didn't:
`ApplicationConfigSpec.scala:134` still asserts
`maxWorkflowWebsocketRequestPayloadSizeKb shouldBe 64`, and `build / amber
(ubuntu-latest, 17)` is already failing on it with `(Config / Test / test)
sbt.TestsFailedException`.
Worth knowing why that isn't obvious from the checks list: `Config/jacoco`
runs only in the amber job (`.github/workflows/build.yml:311`). The `platform
(config-service)` entry runs `ConfigService/jacoco`, a different sbt project
(`build.sbt:121` vs `build.sbt:128`), so all six platform checks stay green
while the build is broken.
##########
bin/k8s/values.yaml:
##########
@@ -310,7 +310,7 @@ texeraEnvVars:
- name: SCHEDULE_GENERATOR_ENABLE_COST_BASED_SCHEDULE_GENERATOR
value: "true"
- name: MAX_WORKFLOW_WEBSOCKET_REQUEST_PAYLOAD_SIZE_KB
- value: "64"
+ value: "1024"
Review Comment:
`bin/k8s/values-development.yaml:310` carries the same env var and still
pins `"64"`, so a deployment rendered from the development chart keeps
reproducing #6857.
Diffing the two charts' `texeraEnvVars` blocks, the only other difference is
the deliberately-different JWT secret — which reads as an oversight rather than
a dev/prod split. The description's "in both places the default is defined"
points the same way; there are three.
This also settles the assumption left open in the thread above: the k8s
entries are "a subset overriding the defaults" only while they agree, and after
this change the two charts disagree.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
