Conversation
stackit_sfs_share could not create, update or delete a share that takes longer than the 10 minutes the SDK wait handlers set, because the resource passed a context without a deadline and the handler default was the only limit. This adds a timeouts attribute following stackitcloud#1740: the default is the wait handler's own timeout plus core.DefaultTimeoutMargin, each CRUD method bounds its context, and a failing wait names the configured timeout through utils.TimeoutHint. The data source gets the read timeout.
With all four timeouts at 10ms the test passed even when Create read the wrong key from the timeouts block. Only create stays short now, so the test fails if the create path stops using timeouts.create.
devpie
force-pushed
the
feat/sfs-share-timeouts
branch
from
September 15, 2026 08:13
97bbc60 to
cb22f44
Compare
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
2 participants
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.
Description
relates to #1737
stackit_sfs_sharehas the problem #1740 fixed forstackit_sfs_resource_pool:CreateShareWaitHandlerand its update and delete counterparts setSetTimeout(10 * time.Minute), and the resource passed a context without a deadline, so that default was the only limit and no configuration could reach it.This adds the
timeoutsattribute in the same shape as #1740:create,read,update,delete; data source:readcore.DefaultTimeoutMargin, so unconfigured resources keep their current behaviourutils.TimeoutHint, the helper feat(sfs): make resource pool wait timeouts configurable #1740 put instackit/internal/utilsTestSfsShareCreateTimeoutmirrorsTestSfsResourcePoolCreateTimeout.testdata/share-max.tfand the max acceptance test configuretimeouts, soTestAccShareResourceMaxcovers the attribute across create, import-verify and update.One wording note: the update wait keeps its
share getdetail instead of following the resource pool'sresource pool update waiting.UpdateShareWaitHandlerpollsGetShareuntil the share reachescreated, and a share has noupdatingstate (sfs@v0.11.2documentspending,creating,created,error,deleting), so after aPATCHthe first poll normally returns straight away. Happy to align the wording with the resource pool if you prefer the symmetry.Overlaps by one line with #1766, which corrects the update diagnostics of the same file. If that one merges first, this branch rebases with a trivial resolution.
Checklist
make fmtexamples/directory) — deliberately not: no example inexamples/carries atimeoutsblock, and feat(dns) add timeouts to dns resources and datasources #1345, which addedtimeoutsto the DNS resources, put the demonstrable configuration intestdatainsteadmake generate-docs(will be checked by CI)make test(will be checked by CI)make lint(will be checked by CI)