bug(services/gdrive): behavior tests failure for Google Drive

[erickguan]

Describe the bug

OpenDAL google drive doesn't pass behavior test in local machine. But works on CI.

Steps to Reproduce

1. export OPENDAL_GDRIVE_ACCESS_TOKEN= from an API explorer
2. Run behavior test OPENDAL_TEST=gdrive cargo test behavior::test_ --features tests,services-gdrive -- --show-output

Expected Behavior

Test passes

Additional Context

Oh lord this is a timing issue. Confirmed with a random 150ms - 1500ms wait on CI too.

• https://github.com/apache/opendal/actions/runs/18603548529/job/53047620830?pr=6701
• https://github.com/apache/opendal/actions/runs/18603606050/job/53047817851?pr=6702

Some possibilities:

1. I looked one specific test case in "list". From logs, I created a folder but then the folder is not presented in lister. The lister doesn't use query cache. This is peculiar. Had if it's not read-after-write, CI tests would not work.
2. PathQuery might be the cult. Though removing caching completely might slow down things a bit.

Are you willing to submit a PR to fix this bug?

• [ ] Yes, I would like to submit a PR.
• [ ] Unblock previously reverted #6683

[Xuanwo]

Thank you for working on this, and sorry we didn’t discuss this earlier. There are no clear rules for such situations. For next time, if we know CI will break, let’s hold off on PRs like https://github.com/apache/opendal/pull/6683 until we figure out how to fix it.

[erickguan]

Totally. @Xuanwo can you ask for behavior test results for non CI services? Or better solution, add an issue to automate this process so we don’t forget.

[Xuanwo]

Totally. @Xuanwo can you ask for behavior test results for non CI services? Or better solution, add an issue to automate this process so we don’t forget.

Yes, it’s a bit tricky. Services like gdrive can’t run on PRs from forked repos. And I actually don’t want contributors to take responsibility for testing—it’s our job. But right now, I don’t have better ideas. Sad.

[Xuanwo]

Maybe we could add triggered actions that committers can use when needed. For example, we can commant a /test in PR, and something magic will use this PR to test, balabala.

The key requirement here is that ONE committer must trigger the test, since the credentials are only available in this repo.

[erickguan]

@Xuanwo merge queue is also a good way. Enqueuing PR -> Merge queue -> tests run on merge queue -> master PR runs. Enough to block master from breaking.