Lesson 359 · AWS Learning Path

AWS 359: Pipeline source events, triggers, filters, concurrency, and superseded executions

Anil Jalela · Published Jun 19, 2026 · 5 min read

Why this lesson matters

A pipeline can deploy the wrong revision even when every action is technically successful. Source events may be duplicated or delayed, filters may overlap, a manual run may bypass expected metadata, and concurrent executions can reach a shared environment in an unsafe order.

This lesson treats initiation and concurrency as distributed-system design. You will define event identity, filter truth tables, deduplication, execution-mode semantics, cancellation, restart, and evidence.

Event-to-release chain

source mutation -> provider event/webhook/EventBridge event
 -> authenticated connection/rule -> filter evaluation
 -> pipeline execution + source revision resolution
 -> execution mode arbitration -> stages/actions -> deployment

Record event ID/time/source, repository/ref, before/after revision, delivery attempt, matched rule, pipeline execution ID, resolved revision, artifact digest, and final deployment ID. A commit ID in an event does not prove the source action actually emitted that revision.

Trigger sources

Source actions can use managed connections, native AWS source services, EventBridge rules, polling for legacy integrations, schedules, API/manual starts, or upstream pipelines. Each has identity, availability, filtering, retry, and audit behavior.

Avoid simultaneous polling and event triggers unless duplicate executions are intentionally controlled. Treat manual starts and source-revision overrides as privileged changes with reason, approver, exact revision, and audit trail.

Filter design

V2 Git triggers can filter events such as pushes and pull-request changes by branches, tags, and file paths according to supported provider/action behavior. Design from examples, then test a truth table:

Test include/exclude precedence, renamed/deleted files, merge commits, multiple changed paths, case sensitivity, glob boundaries, tags versus branches, and provider event types. A path filter can be unsafe for monorepos when shared libraries or pipeline definitions are omitted.

Event delivery and deduplication

Assume at-least-once delivery unless the provider contract proves otherwise. Keep an idempotency record keyed by source system + event ID, or by release intent such as repository/ref/revision/trigger type when event IDs can differ. Retain it beyond the maximum redelivery window.

Do not deduplicate distinct manual reruns that intentionally target the same revision; give them a new release-attempt ID linked to the original. Distinguish:

• duplicate event: same intent accidentally delivered again;
• retry: same execution/action attempts recovery;
• restart: selected failed execution actions run again where supported;
• replay: historical event intentionally processed;
• redeploy: new release attempt for an existing immutable artifact.

Execution modes by state behavior

SUPERSEDED

Newer executions can supersede older ones that have not advanced beyond the relevant stage boundary. In-progress actions are not necessarily killed immediately. Use when only the newest desired state matters and deployment/data operations are safe. Do not use for ordered database migrations or financial event processing without stronger sequencing.

QUEUED (V2)

Executions wait and proceed in order. Use when every revision must traverse a shared environment. Monitor queue age and decide whether obsolete queued releases should be canceled through an approved process rather than wasting capacity.

PARALLEL (V2)

Executions proceed independently and do not share ordinary pipeline state. Use for isolated targets such as per-branch ephemeral environments. Never point parallel executions at one mutable environment, shared database migration, fixed artifact key, or singleton integration test without external locking/isolation.

Concurrency scenarios

Model commits A, B, and C arriving while A is building, awaiting approval, and deploying. For each mode answer:

• which executions are active, queued, or superseded;
• which artifacts remain available;
• whether an approval for A can accidentally authorize B;
• which revision can reach staging/production;
• what happens if A has already written data;
• what cancel/restart/redeploy action is safe.

Approval must bind execution, revision, and digest. A generic “approve production” link that later displays another execution is an unsafe interface.

Cancellation and stop behavior

Stopping an execution is a control-plane action. Provider actions may already have submitted an asynchronous build, stack update, or deployment. Determine whether “stop and wait” or “abandon” semantics are available and what the provider continues doing. After cancellation, query provider state and reconcile side effects.

Never assume cancellation equals rollback. Preserve artifact and logs, mark release state, identify data writes, and decide roll-forward/redeploy/reconciliation.

Read-only evidence commands

aws codepipeline get-pipeline --name PIPELINE_NAME --region ap-south-1
aws codepipeline list-pipeline-executions --pipeline-name PIPELINE_NAME --max-results 20 --region ap-south-1
aws codepipeline get-pipeline-state --name PIPELINE_NAME --region ap-south-1
aws events list-rules --event-bus-name default --region ap-south-1

For one execution, use the authorized detail APIs/console to correlate source revision and action IDs. Redact names, ARNs, account IDs, branch names, commit messages, and artifact locations.

Failure diagnosis ladder

1. Did the source mutation occur and become durable?
2. Did the provider emit the expected event type?
3. Did connection/rule authentication and delivery succeed?
4. Which include/exclude filter matched?
5. Was the event deduplicated, throttled, dead-lettered, or retried?
6. Did CodePipeline create an execution?
7. Which revision did the source action resolve?
8. How did execution mode arbitrate it?
9. Did an action submit external work before stop/supersession?
10. Which artifact and version actually reached the target?

Failure-injection exercise

Simulate 12 cases: duplicate push event, delayed old event after new event, branch/tag name collision, overlapping filters, shared-library path omitted, force-moved tag, connection revoked, EventBridge target denied, queue grows during outage, parallel executions share artifact key, execution superseded after deployment submission, and manual override targets unreviewed revision.

For each provide timeline, expected mode result, evidence fields, customer/data risk, containment, recovery, and permanent test.

Acceptance

Submit trigger inventory, event schema, filter truth table with at least 20 cases, deduplication design, A/B/C concurrency timeline for all modes, approval binding, cancel/restart/redeploy state machine, telemetry/alarms, 12 failure records, cost/throttle analysis, and residual risks.

Pass requires exact revision/digest correlation, no duplicate production deployment, explicit old-event behavior, safe shared-state concurrency, provider-state reconciliation after cancel, and no claim that supersession reverses side effects.

Official sources

• CodePipeline triggers
• How pipeline executions work
• Execution modes
• Stop a pipeline execution
• EventBridge delivery and retries