Conversation
The six status data sources each carried the same ~105 line Read: fetch, nil check, short-circuit on the applied spec revision, build a poll closure, wait, re-fetch, nil check, set state. Only the client method, response field and model type differed, and the copies had already drifted apart. Move the flow into common.ReadEnvStatus, driven by one refresh closure per provider that fetches the status, writes it into the model and reports what the wait needs. WaitForSpecRevision becomes unexported and takes that closure, so the env name is no longer threaded through it. Also collapses the DISCONNECTED branch, whose two arms both appended to blockingErrors and continued. No behaviour change, except that the read timeout is now parsed before the short-circuit rather than only on the waiting path, so a malformed timeouts block is reported either way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Six status data sources — aws, gcp, azure, hcloud, k8s and aws_hosted — each carried the same ~105 line
Read: fetch, nil check, short-circuit on the applied spec revision, build a poll closure, wait, re-fetch, nil check, set state. Only the client method, the response field and the model type differed.The copies had already drifted:
"env status matchs spec"in azure, gcp, hcloud and k8s; aws and aws_hosted spelled it correctly// Re-fetch to populate the modelcomment existed in two of the sixBoth are the kind of thing that only shows up as a diff between siblings nobody diffs.
Shape
common.ReadEnvStatusowns the flow. Each provider supplies onerefreshclosure that fetches the status, writes it into its model and returns what the wait needs (AppliedSpecRevision,Errors,Found).WaitForSpecRevisionbecomes unexported and takes that same closure, which drops thePollFunctype and stops threading the env name through it.Per-provider
Readgoes from ~105 lines to ~45, and what is left is the binding — client method, response field, model — with no control flow.Also collapses the
DISCONNECTEDbranch in the wait, whose two arms both didblockingErrors = append(...)thencontinue:Behaviour
Unchanged, with one exception worth flagging: the read timeout is now parsed before the short-circuit rather than only on the waiting path, so a malformed
timeoutsblock is reported in both cases instead of only when a wait happens.Tests
env_status/commonhad no tests; the flow now has 11, covering no target, target already met, refresh error, not found, refresh-after-wait, timeout,DISCONNECTED/K8S_DISCONNECTEDbefore first provision, disconnect after provisioning, a plain provisioning error, and a blocking error arriving alongside a non-blocking disconnect.