Auth failure

Dev to Dev Hub
1

Repeated API reads show all_changes_deployed=true from GET Action, but false for the same Action in GET post-login trigger bindings. Both reference the same deployed version and matching

source code. The specific version reports deployed=true and status=built.

Can the binding-side flag legitimately differ? Which documented read-only check establishes the actual deployed state? We have not redeployed or rebound anything to force agreement.

3

Hi @tom30

You are reporting a discrepancy in Auth0 Actions API responses: when you call GET on an Action, it returns all_changes_deployed=true, but when you call GET on the post-login trigger bindings for the same Action, it returns all_changes_deployed=false. Both reference the same deployed version with matching source code, and the specific version reports deployed=true and status=built. You want to know if the binding-side flag can legitimately differ, and which documented read-only check establishes the actual deployed state.

This appears to be a state consistency issue in the Auth0 Actions API. The all_changes_deployed flag should be consistent between the Action endpoint and the trigger binding endpoint when both reference the same deployed version. If they are reporting different values without any redeployment or rebinding, this indicates either a caching issue, eventual consistency delay, or a bug in the API. Contact Auth0 Support to clarify which endpoint is authoritative and whether this discrepancy requires investigation.

Root Cause:

The discrepancy you're observing suggests one of the following:

  1. Eventual consistency delay — The trigger binding endpoint may be reading from a cache or replica that hasn't yet been updated with the latest deployment state
  2. Separate state tracking — The Action object and the trigger binding may track deployment state independently, and they may not always be synchronized
  3. API bug or inconsistency — There may be a bug in how Auth0 reports all_changes_deployed across different endpoints
  4. Different deployment contexts — The Action's deployment state and the binding's deployment state may represent different things (e.g., the Action is deployed, but the binding hasn't been applied)
  5. Stale data — One of the endpoints may be returning cached data that hasn't been refreshed

Understanding Auth0 Actions Deployment States:

Auth0 Actions have multiple related concepts:

  1. Action status — built or unbuilt (whether the code compiles)
  2. Action deployment — deployed=true/false (whether the Action version is deployed)
  3. all_changes_deployed — Whether all code changes in the Action have been deployed
  4. Trigger binding — Whether the Action is bound to a trigger flow
  5. Binding deployment state — Whether the binding itself is deployed

API Endpoints Involved:

GET /api/v2/actions/actions/{id}
  Returns: Action object with deployed, status, all_changes_deployed

GET /api/v2/actions/triggers/{trigger_id}/bindings
  Returns: Trigger binding object with all_changes_deployed (per binding)

Recommended Troubleshooting Steps:

Step 1: Verify the Exact API Responses

  1. Call GET Action endpoint: 
    curl -H "Authorization: Bearer $TOKEN" \
  https://YOUR_DOMAIN/api/v2/actions/actions/{ACTION_ID}
  2. Note the response:
    • id
    • deployed
    • status
    • all_changes_deployed
    • built_at (timestamp)
  3. Call GET trigger bindings endpoint: 
    curl -H "Authorization: Bearer $TOKEN" \
  https://YOUR_DOMAIN/api/v2/actions/triggers/post-login/bindings
  4. Find your Action in the bindings and note:
    • action_id
    • all_changes_deployed
    • created_at / updated_at
  5. Compare timestamps — Check if the binding was updated more recently than the Action

Step 2: Check for Eventual Consistency

  1. Wait 30-60 seconds and repeat the API calls
  2. Check if the values converge — If they do, this indicates eventual consistency
  3. Document the timing — Note how long it takes for consistency

Step 3: Verify the Deployed Version

  1. Get the Action's current version: 
    curl -H "Authorization: Bearer $TOKEN" \
  https://YOUR_DOMAIN/api/v2/actions/actions/{ACTION_ID}/versions
  2. Verify that the binding references the same version: 
    curl -H "Authorization: Bearer $TOKEN" \
  https://YOUR_DOMAIN/api/v2/actions/triggers/post-login/bindings
  3. Compare version IDs — Ensure both are using the same version

Step 4: Check the Source Code

  1. Get the Action's source code: 
    curl -H "Authorization: Bearer $TOKEN" \
  https://YOUR_DOMAIN/api/v2/actions/actions/{ACTION_ID}/versions/{VERSION_ID}/code
  2. Verify that the code matches what you expect

Step 5: Force a Consistency Check

If the values remain inconsistent:

  1. Redeploy the Action (without code changes):
    • Go to Auth0 Dashboard → Actions → Library
    • Click the Action
    • Click "Deploy" button
    • Check if all_changes_deployed becomes consistent
  2. Rebind the Action (without changes):
    • Go to Auth0 Dashboard → Actions → Flows → Post-Login
    • Remove the binding
    • Re-add the binding
    • Check if all_changes_deployed becomes consistent
  3. Document the results — Note whether forcing a redeploy/rebind resolves the discrepancy

What to Report to Auth0 Support:

If the discrepancy persists after troubleshooting:

  1. Provide the Action ID and tenant name
  2. Include the exact API responses:
    • GET /api/v2/actions/actions/{ACTION_ID} response
    • GET /api/v2/actions/triggers/post-login/bindings response (filtered to your Action)
  3. Include timestamps:
    • When you first observed the discrepancy
    • When you made the API calls
    • Any recent deployments or rebindings
  4. Ask specifically:
    • Which endpoint is authoritative for all_changes_deployed?
    • Is this a known issue or eventual consistency behavior?
    • What is the documented behavior for this flag?
    • Should these values always be consistent?

Authoritative Source of Truth:

Based on the available documentation and community discussions:

  1. GET Action endpoint — Likely authoritative for the Action's deployment state
  2. GET trigger bindings endpoint — Likely authoritative for whether the binding is deployed
  3. Neither is explicitly documented as the single source of truth for all_changes_deployed

Recommended Approach:

Until Auth0 clarifies which is authoritative:

  1. Use the Action endpoint (GET /api/v2/actions/actions/{id}) as the primary source for whether an Action is deployed
  2. Use the trigger bindings endpoint to verify that the binding is active and references the correct version
  3. Treat discrepancies as potential issues and report them to Auth0 Support
  4. Implement retry logic in your code to handle eventual consistency (wait and retry if values don't match)

Code Example for Consistency Checking:

async function verifyActionDeploymentConsistency(actionId, triggerId) {
  const maxRetries = 5;
  const delayMs = 2000;

  for (let attempt = 0; attempt < maxRetries; attempt++) {
    // Get Action deployment state
    const actionResponse = await fetch(
      `https://YOUR_DOMAIN/api/v2/actions/actions/${actionId}`,
      { headers: { 'Authorization': `Bearer ${token}` } }
    );
    const action = await actionResponse.json();

    // Get trigger binding state
    const bindingResponse = await fetch(
      `https://YOUR_DOMAIN/api/v2/actions/triggers/${triggerId}/bindings`,
      { headers: { 'Authorization': `Bearer ${token}` } }
    );
    const bindings = await bindingResponse.json();
    const binding = bindings.bindings.find(b => b.action_id === actionId);

    // Check consistency
    if (action.all_changes_deployed === binding.all_changes_deployed) {
      console.log(`✓ Consistent at attempt ${attempt + 1}`);
      return { consistent: true, action, binding };
    }

    console.log(`✗ Inconsistent at attempt ${attempt + 1}, retrying...`);
    
    if (attempt < maxRetries - 1) {
      await new Promise(resolve => setTimeout(resolve, delayMs));
    }
  }

  console.warn('⚠ Inconsistency persists after retries');
  return { consistent: false, action, binding };
}

This discrepancy should not occur without a redeployment or rebinding. Contact Auth0 Support to determine whether this is a caching issue, eventual consistency delay, or a bug in the API.