fix: SetOrgWideDefaults._poll_action fails with stale access token after deploy

[yippie]

Task set_organization_wide_defaults fails 100% of the time if RTR (Refresh token rotation) is on. This is a Connected App security setting that Salesforce now requires and affects CumulusCI when embedded in MetaDeploy.

Root cause

SetOrgWideDefaults._run_task() calls _deploy(), which instantiates a new
Deploy task and invokes api() on it. Deploy.call() always calls
BaseSalesforceTask._update_credentials() → org_config.refresh_oauth_token(),
rotating org_config.access_token AFTER self.sf was already frozen in _init_task().

When _post_deploy() → _poll() → _poll_action() runs, self.sf.query() uses
the pre-deploy access token. If the org has refresh token rotation or a short
session policy, this token is invalid and every poll call returns a 401.

Sequence

Step	Event	org_config.access_token	self.sf.session_id
SetOrgWideDefaults.call()	_update_credentials() → refresh	TOKEN_A	—
_init_task()	self.sf = _init_api()	TOKEN_A	TOKEN_A
_deploy() → Deploy()()	_update_credentials() → refresh again	TOKEN_B	still TOKEN_A ← stale
_post_deploy() → _poll_action()	self.sf.query()	TOKEN_B	TOKEN_A → 401

Fix

Replace self.sf.query(...) with self.org_config.salesforce_client.query(...).

OrgConfig.salesforce_client is a @Property that constructs a fresh
simple_salesforce.Salesforce instance from self.access_token on every
access, so it always uses the current (post-deploy-refresh) token.

Tests

Updated the three _poll_action / _post_deploy tests to mock
org_config.salesforce_client via PropertyMock instead of assigning
directly to task.sf.

[jstvz]

Thanks for the fix — the bug diagnosis is correct. After _deploy() creates a child Deploy task sharing the same org_config, the child's _update_credentials() rotates org_config.access_token, but self.sf on the parent SetOrgWideDefaults still holds the old token.

However, replacing self.sf.query(...) with self.org_config.salesforce_client.query(...) introduces a few behavioral regressions:

1. Lost retry adapter — self.sf (built by get_simple_salesforce_connection) installs an HTTPAdapter with Retry(total=5, status_forcelist=(502, 503, 504), backoff_factor=0.3). salesforce_client creates a bare Salesforce() with no retry adapter. This polling loop runs up to 600 seconds post-deploy, when transient 502/503/504 errors are common.

2. Lost CALL_OPTS_HEADER_KEY — the connection utility sets a client=... header for server-side observability. salesforce_client does not.

3. Object per iteration — salesforce_client is a @property that creates a new Salesforce() on every access, so each poll iteration allocates a fresh client.

Suggested alternative (one-line fix, preserves all existing behavior):

Refresh self.sf once after deploy returns. In _post_deploy, before the polling loop starts:

self.sf = self._init_api()

This re-creates the connection with the current (rotated) token while keeping the retry adapter, the CALL_OPTS_HEADER_KEY header, and the task-configured API version. Single allocation instead of one per poll iteration.

Would you be open to revising the approach? Happy to pair on it if useful.

[yippie]

@jstvz Absolutely, I think I updated per your recommendation