https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT>, I've just added `secretsmanager:De...
# replication-ask-ai
d
@kapa.ai, I've just added 
secretsmanager:DeleteSecret
to the IAM role used by Airbyte, is there way to trigger airbyte to delete the old secrets which previously were not delete because of this missing permission?
k
Thinking completed I'm sorry, but the provided knowledge sources do not mention any command, API endpoint, or mechanism to trigger Airbyte to retroactively clean up or delete orphaned secrets that failed deletion due to past permission errors. According to the documentation, Airbyte automatically deletes old secrets when connector configurations are updated or deleted [Operational Details; Issue: When deleting Source...]. However, there is no documented background reconciliation task or triggerable process to retry deleting secrets that previously failed with an 
AccessDeniedException
. Because these orphaned secrets are named deterministically with the prefix 
airbyte_workspace_<workspace-id>_secret_<uuid>_<version>
(and optionally tagged if you configured tags or 
secretsmanager:ResourceTag/AirbyteManaged
) [Operational Details; AWS Secret Manager Policy], you may need to identify and delete or schedule them for deletion directly within AWS Secrets Manager (for example, via the AWS CLI or AWS Console). šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai from docs.airbyte.com/platform/understanding-airbyte/secrets#ā€¦ > 1. Airbyte deletes old secrets when connector configuration is updated or deleted as of 0.63.10. > does that mean that I can update the connectors config which will trigger secret deletion?
k
Thinking completed The knowledge sources do not explicitly confirm whether updating a connector will successfully delete orphaned secrets that failed deletion during earlier attempts. Here is what the documentation explains about how Airbyte handles updates: 1. How updates work under normal conditions: When a connector configuration is updated, Airbyte generates a new secret coordinate by incrementing the version suffix (for example, 
..._v1
-> 
..._v2
) and deletes the previous version [Operational Details]. 2. Impact on already-orphaned secrets: The provided documentation only states that Airbyte deletes old secrets upon configuration updates or deletions [Operational Details]. It does not specify whether the update process tracks and cleans up previously failed deletions (such as historical 
_v1
secrets that were left behind due to the missing IAM permission when the configuration was moved to 
_v2
), or if it only attempts to delete the immediately preceding secret version. Therefore, while saving an update to an existing connector will attempt to delete the current active secret version as it writes a newer one, there is no guarantee it will retroactively clean up older orphaned secrets that failed to delete in past attempts. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, how can I get all secrets and their versions from airbyte, not from secrets manager
k
Thinking completed The knowledge sources do not mention a way to get a complete list of all historical secret versions directly from Airbyte. However, they do provide ways to view the current secret coordinates and versions associated with existing sources and destinations, as well as where this data lives internally. 1. Retrieving Current Coordinates via the API By default, API read endpoints mask secret values. You can retrieve the currently referenced secret coordinate (which includes the deterministic version suffix, e.g., 
_v1
or 
_v2
) for active connectors using the 
includeSecretCoordinates
parameter [Operational Details; Terraform Example]: ā€¢ Public Source Read: 
GET /public/v1/sources/{sourceId}?includeSecretCoordinates=true
[Terraform Example] ā€¢ Public Destination Read: 
GET /public/v1/destinations/{destinationId}?includeSecretCoordinates=true
[Terraform Example] ā€¢ Internal Source Read: 
POST /v1/sources/get_with_metadata
with 
"includeSecretCoordinates": true
in the request body [Terraform Example] _(Note: The standard internal endpoints 
POST /v1/sources/get
and 
POST /v1/destinations/get
always mask secrets, and Airbyte does not provide an internal 
POST /v1/destinations/get_with_metadata
endpoint [Terraform Example].)_ 2. Direct Database Storage Airbyte stores configurations internally as JSON blobs within its internal database [Secrets]. For fields configured as secrets, it replaces the field's plain value with an obfuscated object containing the active coordinate:
Copy code
{
  "api_token": {
    "_secret": "airbyte_workspace_4e7d7911-0307-40fe-9b79-f00c0dfbb082_secret_d66baab6-3c8d-4ae5-91a6-ca8d904c4780_v1"
  }
}
[Secrets] Limitations The knowledge sources do not document any API, CLI command, or query to retrieve past versions or orphaned secret coordinates (e.g., historical versions like 
_v1
that were overwritten by a 
_v2
update or belonged to already-deleted connectors). In Airbyte, only the currently active secret coordinate is retained in the connector's configuration blob [Secrets; Operational Details]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, I have 24 sources and 5 destionations, does that mean that I should have 29 secrets?
k
Thinking completed No, having 24 sources and 5 destinations does not mean you will have exactly 29 secrets. You will likely have a different number (and potentially significantly more), for several reasons: 1. Multiple secrets per connector: Airbyte creates a separate secret coordinate for each individual field marked with 
"airbyte_secret": true
in a connector's specification, rather than one per connector [Secrets]. For example, a single source using OAuth might generate three separate secrets (e.g., Client ID, Client Secret, and Refresh Token) [Issue: When deleting Source...]. 2. Connectors without secrets: Some sources or destinations may not require any secret fields at all (or may use unauthenticated local configurations), meaning they generate zero secrets [Secrets]. 3. Non-connector secrets: Airbyte also creates secrets for other platform models, such as webhook configurations [Secrets]. 4. Temporary / check secrets: Airbyte generates secrets during temporary operations such as "Check Connection" or "Discover" operations (which use the workspace ID 
00000000-0000-0000-0000-000000000000
), though Airbyte attempts to expire these after 2 hours [Operational Details]. 5. Orphaned versions: If secrets failed to delete previously (for example, due to the missing 
secretsmanager:DeleteSecret
IAM permission when updating configurations), older versioned secrets (like 
_v1
) may still remain in your secret store alongside the active ones [Operational Details; Issue: When deleting Source...]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, is it safe to delete all secrets for all UUIDs expect the latest version for this specific UUID ? FO example is it safe to delete: 9493538c-b823-4478-a17a-df3f8f121916_v42 9493538c-b823-4478-a17a-df3f8f121916_v43 9493538c-b823-4478-a17a-df3f8f121916_v44 9493538c-b823-4478-a17a-df3f8f121916_v45 9493538c-b823-4478-a17a-df3f8f121916_v5 9493538c-b823-4478-a17a-df3f8f121916_v6 9493538c-b823-4478-a17a-df3f8f121916_v7 9493538c-b823-4478-a17a-df3f8f121916_v8 9493538c-b823-4478-a17a-df3f8f121916_v9 26700265-1944-4ef2-91f4-33a44e7a5313_v1 by leaving only 9493538c-b823-4478-a17a-df3f8f121916_v46 (highest version) ?
k
Thinking completed Yes, deleting the older versions for an existing secret coordinate is generally safe and aligns with Airbyte's intended design [Operational Details]. Here is why, along with a few precautions: How Airbyte Uses Secret Versions ā€¢ Airbyte only references the current version: When connector configuration is updated, Airbyte increments the version suffix (e.g., from 
_v45
to 
_v46
) and updates the stored JSON configuration to point specifically to that new coordinate [Secrets; Operational Details]. Airbyte only reads and hydrates the active coordinate embedded in the JSON [Secrets]. ā€¢ Old versions were meant to be deleted: Under normal operations, Airbyte automatically deletes previous secret versions as soon as a configuration is updated (e.g., when moving to a new version) [Operational Details; Issue: When deleting Source...]. The older versions (
_v5
through 
_v45
) only accumulated because the 
secretsmanager:DeleteSecret
permission was previously missing [Issue: When deleting Source...]. Precautions to Take 1. Verify the active version first: To be completely certain that 
_v46
is the actively referenced secret and not an orphaned version from a subsequent deleted/changed connector, check the active coordinate on the source/destination using the API (
?includeSecretCoordinates=true
) or inspect the connector JSON in the database [Secrets; Terraform Example]. 2. AWS Secrets Manager Recovery Window: By default, AWS Secrets Manager does not immediately permanently delete a secret; it schedules it for deletion with a recovery window (typically 7 to 30 days). This allows you to restore a secret if needed. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, what will happen if I delete even the latest version? will airbyte recreate it, will the source/dest/connection stops working?
k
Thinking completed If you delete the latest (active) version of a secret from AWS Secrets Manager, the source, destination, or connection will stop working, and Airbyte will not automatically recreate it. Based on the knowledge sources, here is what happens: 1. Airbyte cannot recreate deleted secret payloads: Airbyte only stores the obfuscated coordinate (e.g., 
{"_secret": "airbyte_workspace_..._secret_<uuid>_v46"}
) in its database, not the actual plain-text secret value [Secrets]. Because Airbyte no longer has the raw secret stored anywhere else, it has no way to recreate the secret in AWS Secrets Manager if the active version is removed. 2. Syncs and operations will fail: Before running any connector job or operation, Airbyte reads the configuration, looks up the specific coordinate referenced in the JSON blob, and attempts to hydrate the secret [Secrets; Module airbyte_agent_sdk.secrets_aws]. If that secret is missing from AWS Secrets Manager: ā—¦ The secret hydration fails [Module airbyte_agent_sdk.secrets_aws]. ā—¦ Connection syncs, connection tests, and discover checks will fail with errors indicating that the secret coordinate cannot be resolved [Module airbyte_agent_sdk.secrets_aws]. If an active secret is accidentally deleted: ā€¢ You can restore or cancel the deletion in AWS Secrets Manager (if it is within the scheduled deletion recovery window). ā€¢ Alternatively, you will have to manually update the connector configuration in Airbyte to re-enter the credentials, which forces Airbyte to write a new secret version to Secrets Manager [Values; Operational Details]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, what could be the reason for a secret UUID to not be found in airbyte's DB? usually I can find the UUIDs like this: SELECT * FROM actor WHERE configuration::text ILIKE '%26700265-1944-4ef2-91f4-33a44e7a5313%'; but this specific one is not found, however there are secrets in the secrets manager which have this UUID. I have 37 versions for this UUID
k
Thinking completed Based on the provided knowledge sources, there are a few likely reasons why a secret UUID exists in AWS Secrets Manager but is not present in the 
actor.configuration
column: 1. The Connector (Actor) Was Deleted When a connector (source or destination) is deleted from Airbyte, its record in the database may be removed or marked as tombstoned, and Airbyte triggers a cleanup of its secrets in the secret store [Issue: When deleting Source...]. Because your IAM role was previously missing the 
secretsmanager:DeleteSecret
permission, the secret deletion failed [Issue: When deleting Source...]. As a result, the secrets remained orphaned in AWS Secrets Manager even though the connector was already deleted from Airbyte. (Note: Depending on how the query is run, if the connector was soft-deleted, check whether records exist with 
tombstone = true
in the 
actor
table [Airbyte Databases Data Catalog].) 2. The Secret Belongs to a Non-Actor Model (e.g., Webhooks) Airbyte handles secrets for models across the entire platform, not just connector configurations in the 
actor
table: > "While this is most often seen in Connector configuration, this hold true for all models, including Platform models such as webhook configuration." [Secrets] If this secret belongs to another entity, such as a workspace webhook or notification configuration, its coordinate will reside in a different database table rather than 
actor
. 3. The Connector's Spec Changed or the Secret Was Replaced If a connector was reconfigured, converted to a different authentication method (e.g., switching from OAuth to API token), or updated such that a specific secret field was removed from its configuration, the coordinate for that field would no longer be present in 
actor.configuration
. Because prior versions could not be deleted without the IAM permission, they remained in Secrets Manager [Operational Details; Issue: When deleting Source...]. What to check: ā€¢ Check the Workspace ID: Look at the full secret name prefix in Secrets Manager (
airbyte_workspace_<workspace-id>_secret_<uuid>_<version>
) [Secrets]. ā—¦ If the workspace ID is 
00000000-0000-0000-0000-000000000000
, it was created during a transient operation (such as a Discover or Check Connection test) and is not attached to an actor [Operational Details; Issue: Discover / Check secrets...]. ā—¦ If it has an active workspace ID, it belonged to a source, destination, or platform model within that workspace that has since been deleted or modified [Secrets; Operational Details]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai , can I find this UUID somewhere in the logs stored in s3 ?
k
Thinking completed The knowledge sources do not explicitly confirm whether you will be able to find that specific secret UUID within your S3 logs, but there are a few documented details regarding how Airbyte logs secrets and deletion errors: 1. Airbyte Server and Worker Logs (Deletion Failures): When Airbyte attempts to delete a secret coordinate from persistence, it logs messages containing the full coordinate:If your deployment forwards platform, server, or worker logs to S3 (such as through standard container log collection or S3 logging storage) [Collect Logs from a Flex Data Plane; Issue: Worker process... fails to start...], you may find this UUID in logs corresponding to the times the connector was updated or deleted and encountered an 
AccessDeniedException
[Issue: When deleting Source...]. ā—¦ 
Deleting: airbyte_workspace_<workspace-id>_secret_<uuid>_<version>
ā—¦ 
Error deleting secret: airbyte_workspace_<workspace-id>_secret_<uuid>_<version>
[Issue: When deleting Source...] 1. Sync and Connector Logs: The knowledge sources do not specify whether the obfuscated secret coordinate string itself is written to connection sync logs stored in S3. However, the raw secret value is masked and never printed in logs [Secrets; Collect Logs from a Flex Data Plane]. 2. Audit Logs: Audit logs omit credentials and secret identifiers (including 
secretId
and 
connectionConfiguration
) by default [What Airbyte doesn't record], so you will not find the secret UUID in audit log records. In summary, searching your S3 server/platform logs for the UUID 
26700265-1944-4ef2-91f4-33a44e7a5313
or the string 
Error deleting secret
may reveal the deletion error and the context (such as the workspace ID or action) if server logs were routed to S3 [Issue: When deleting Source...]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, i get the following error:
Copy code
2026-09-14 13:36:23,328 [io-executor-thread-38]	[1;31mERROR[0;39m	i.a.s.a.ApiHelper(execute):47 - Unexpected Exception
io.airbyte.commons.server.errors.IdNotFoundKnownException: Could not find attempt stats for job_id: 14305 and attempt no: 0
	at io.airbyte.commons.server.handlers.AttemptHandler.getAttemptCombinedStats(AttemptHandler.kt:239)
	at io.airbyte.server.apis.controllers.AttemptApiController.getAttemptCombinedStats$lambda$0(AttemptApiController.kt:66)
	at io.airbyte.server.apis.ApiHelper.execute(ApiHelper.kt:32)
	at io.airbyte.server.apis.controllers.AttemptApiController.getAttemptCombinedStats(AttemptApiController.kt:65)
	at io.airbyte.server.apis.controllers.$AttemptApiController$Definition$Exec.dispatch(Unknown Source)
	at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invokeUnsafe(AbstractExecutableMethodsDefinition.java:461)
	at io.micronaut.context.DefaultBeanContext$BeanContextUnsafeExecutionHandle.invokeUnsafe(DefaultBeanContext.java:4454)
	at io.micronaut.web.router.AbstractRouteMatch.execute(AbstractRouteMatch.java:272)
	at io.micronaut.web.router.DefaultUriRouteMatch.execute(DefaultUriRouteMatch.java:38)
	at io.micronaut.http.server.RouteExecutor.executeRouteAndConvertBody(RouteExecutor.java:466)
	at io.micronaut.http.server.RouteExecutor.lambda$callRoute$5(RouteExecutor.java:443)
	at io.micronaut.core.execution.ExecutionFlow.lambda$async$0(ExecutionFlow.java:92)
	at io.micronaut.core.propagation.PropagatedContext.lambda$wrap$3(PropagatedContext.java:232)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
	at java.base/java.lang.Thread.run(Thread.java:1583)

2026-09-14 13:36:23,330 [io-executor-thread-38]	[1;31mERROR[0;39m	i.a.c.s.e.h.IdNotFoundExceptionHandler(handle):35 - Id not found exception [errorId: 4a21fc42-e669-4756-b426-ac39048c189a]: class NotFoundKnownExceptionInfo {
    id: 14305_0
    message: Could not find attempt stats for job_id: 14305 and attempt no: 0
    exceptionClassName: io.airbyte.commons.server.errors.IdNotFoundKnownException
    exceptionStack: [io.airbyte.commons.server.errors.IdNotFoundKnownException: Could not find attempt stats for job_id: 14305 and attempt no: 0, 	at io.airbyte.commons.server.handlers.AttemptHandler.getAttemptCombinedStats(AttemptHandler.kt:239), 	at io.airbyte.server.apis.controllers.AttemptApiController.getAttemptCombinedStats$lambda$0(AttemptApiController.kt:66), 	at io.airbyte.server.apis.ApiHelper.execute(ApiHelper.kt:32), 	at io.airbyte.server.apis.controllers.AttemptApiController.getAttemptCombinedStats(AttemptApiController.kt:65), 	at io.airbyte.server.apis.controllers.$AttemptApiController$Definition$Exec.dispatch(Unknown Source), 	at io.micronaut.context.AbstractExecutableMethodsDefinition$DispatchedExecutableMethod.invokeUnsafe(AbstractExecutableMethodsDefinition.java:461), 	at io.micronaut.context.DefaultBeanContext$BeanContextUnsafeExecutionHandle.invokeUnsafe(DefaultBeanContext.java:4454), 	at io.micronaut.web.router.AbstractRouteMatch.execute(AbstractRouteMatch.java:272), 	at io.micronaut.web.router.DefaultUriRouteMatch.execute(DefaultUriRouteMatch.java:38), 	at io.micronaut.http.server.RouteExecutor.executeRouteAndConvertBody(RouteExecutor.java:466), 	at io.micronaut.http.server.RouteExecutor.lambda$callRoute$5(RouteExecutor.java:443), 	at io.micronaut.core.execution.ExecutionFlow.lambda$async$0(ExecutionFlow.java:92), 	at io.micronaut.core.propagation.PropagatedContext.lambda$wrap$3(PropagatedContext.java:232), 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144), 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642), 	at java.base/java.lang.Thread.run(Thread.java:1583), ]
    rootCauseExceptionClassName: null
    rootCauseExceptionStack: []
    errorId: 95186108-728d-42d1-b4e9-ac94512dab4f
}
k
Thinking completed The knowledge sources do not provide an explicit, documented fix for this specific stack trace (
IdNotFoundKnownException: Could not find attempt stats for job_id: 14305 and attempt no: 0
), but they do explain why attempt stats can be missing in Airbyte. What is Happening When a client (such as the Airbyte UI or an API caller) requests the statistics for a sync attempt via the internal 
AttemptApiController.getAttemptCombinedStats
endpoint, the server looks up the attempt's stats in the platform database (such as the 
attempts
and 
sync_stats
tables) [Discussions: 80162; Forum Post: 4016]. If the database has no recorded statistics for that attempt, Airbyte throws an 
IdNotFoundKnownException
reporting that it 
Could not find attempt stats for job_id: ... and attempt no: 0
[Forum Post: 4016; Bug fixes]. In other handlers, this same underlying issue commonly logs as 
WARN/ERROR ... Missing stats for job <id> attempt <num>
[Issues: 55812; Forum Post: 3804; Forum Post: 4016]. Common Causes 1. The attempt died before emitting or recording stats: If the pod running the attempt was killed externally (e.g., node autoscaling, spot termination, OOM killed) or crashed very early during initialization before replication started and recorded 
SyncStats
, no stats record is written to persistence [SyncStats.yaml; Issues: 48879; Issues: 84961]. 2. Job was cancelled or pending: Jobs cancelled while in pending/queued status or during early container boot often do not write attempt stats [Issues: 55812]. When the UI opens the job history page, it tries to fetch stats for all attempts of the job, triggering this error for attempts that have none [Forum Post: 3804; Forum Post: 4016]. 3. UI / Polling noise: Airbyte team members have noted in community discussions that missing stats errors are often logged repeatedly as noise when the server or UI polls for attempt details while no stats exist [Forum Post: 3804; Forum Post: 4016]. What You Can Check ā€¢ Check the status of job 
14305
using the API (
GET /jobs/14305
) or the UI to see whether attempt 
0
failed, was cancelled, or crashed early [Airbyte Public API - Jobs; Issues: 55812]. ā€¢ If the sync job is still actively running or failed due to a worker crash, look at the orchestrator/worker logs for attempt 0 to verify why it terminated before persisting stats [Review connection timeline; Issues: 48879]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, please provide full curl command for this
k
Thinking completed To get the status and details for job 
14305
using the Airbyte API, here are the full 
curl
commands based on the available documentation: Using the Public API (GET /jobs/{jobId}) If you are calling the Airbyte Public API [getJob]:
Copy code
curl -X GET "https://api.airbyte.com/v1/jobs/14305" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer <YOUR_ACCESS_TOKEN>"
(Note: Depending on your deployment and configuration, the Public API endpoint may require an application bearer token [Airbyte Public API - Jobs; Clickup-Api authentication]). Using the Internal API on Self-Managed / OSS If you are querying a self-hosted instance directly (for example, on 
http://localhost:8000
) using default basic credentials [Test the API endpoints with cURL]:
Copy code
curl -u 'airbyte:password' -X POST "http://localhost:8000/api/v1/jobs/get" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"id": 14305}'
šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, can I delete secrets with workplace id 
00000000-0000-0000-0000-000000000000
?
k
Thinking completed Yes, it is safe to delete secrets associated with the workspace ID 
00000000-0000-0000-0000-000000000000
. Why these secrets exist According to the documentation: ā€¢ Secrets with the workspace ID 
00000000-0000-0000-0000-000000000000
are created during transient operations such as Discover or Check Connection tests, where credentials cannot yet be associated with a real workspace [Operational Details]. ā€¢ These secrets are temporary. Airbyte's intended behavior is to automatically expire and clean them up after 2 hours for security and cost reasons [Operational Details]. Why they are still there If your deployment previously had missing IAM permissions (or encountered known issues where Airbyte fails to trigger cleanup for check/discover secrets), these temporary secrets were left behind in your secret manager rather than expiring as intended [Operational Details; Issue: Discover / Check secrets...]. Because active connectors belong to actual workspace UUIDs and not 
00000000-0000-0000-0000-000000000000
, running sync jobs and saved connectors do not rely on these secrets, making them safe to delete [Operational Details; Issue: Discover / Check secrets...]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
d
@kapa.ai, if I have secrets were were created more than 10 days ago and were never retrieved can these be deleted?
k
Thinking completed The knowledge sources do not explicitly state whether it is guaranteed to be safe to delete secrets solely based on creation age (e.g., more than 10 days old) and a "never retrieved" status in your secrets manager. However, based on how Airbyte operates, here is what you need to consider: 1. Check Operations vs. Active Connectors ā€¢ Discover / Check Secrets: If the secret coordinate starts with 
airbyte_workspace_00000000-0000-0000-0000-000000000000
, it was created for a temporary test and Airbyte intends for it to expire after 2 hours [Operational Details]. Any of these older than 10 days are orphaned and safe to delete [Operational Details; Issue: Discover / Check secrets...]. ā€¢ Dormant or Infrequently Synced Connectors: If a secret belongs to an active workspace UUID, the fact that it has not been accessed in 10 days could simply mean:Airbyte only reads and hydrates secrets from the secret manager when an operation runs (e.g., running a sync, checking a connection, or reading metadata) [Secrets; Module airbyte_agent_sdk.secrets_aws]. If an active connector has not run in 10 days, its secret will not have been retrieved, but deleting it will break the connector when it is eventually triggered [Module airbyte_agent_sdk.secrets_aws]. ā—¦ The connection is configured on a manual schedule or runs less frequently than every 10 days [Sync Schedule]. ā—¦ The connection is paused/disabled, but the source or destination is still configured and intended to be used later. 2. Older Versions of Existing Coordinates If the secret is an older version suffix (e.g., 
_v1
, 
_v2
) for a coordinate that currently has a higher version (e.g., 
_v3
), Airbyte only references the newest version in its database [Operational Details]. Those older versions are never retrieved again and are safe to delete [Operational Details; Issue: When deleting Source...]. Recommendation Instead of relying solely on the creation date or retrieval history: 1. Cross-reference the secret's coordinate UUID against the 
actor
table configuration or fetch the active secret coordinates via the Airbyte API using 
?includeSecretCoordinates=true
[Secrets; Terraform Example]. 2. If the UUID is not referenced in any active source, destination, or platform model, or belongs to the 
00000000-0000-0000-0000-000000000000
workspace, it is safe to delete [Secrets; Operational Details]. šŸ‘ 0 button šŸ‘Ž 0 button ā„¹ļø Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.
2 Views
Open in Slack
PreviousNext
Powered by