Gemini Code Assist wird nur in VS Code mit der Erweiterung „Gemini Code Assist + Cloud Code“ version+ unterstützt.
Auf dieser Seite sind bekannte Probleme mit Eventarc Standard aufgeführt.
Außerdem können Sie in der öffentlichen Problemverfolgung prüfen, ob Probleme vorhanden sind, und neue Probleme eröffnen.
Es kann bis zu zwei Minuten dauern, bis neu erstellte Trigger bereit sind.
Wenn Sie einen Trigger aktualisieren,
bevor das generierte Ereignis gesendet wird,
wird das Ereignis entsprechend der vorherigen Filterung weitergeleitet und wird innerhalb von drei Tagen nach der Ereignisgenerierung an das ursprüngliche Ziel gesendet. Die neuen Filter werden auf Ereignisse angewendet,
die nach der Aktualisierung generiert wurden.
Es gibt eine bekannte doppelte Übertragung von Cloud-Audit-Logs aus einigenGoogle Cloud -Ereignisquellen. Wenn doppelte Logs veröffentlicht werden, werden doppelte Ereignisse an Ziele gesendet. Um diese doppelten Ereignisse zu vermeiden, sollten Sie Trigger für Felder erstellen, die gewährleisten, dass das Ereignis eindeutig ist.
Dies gilt für die folgenden Ereignistypen:
Da Workflows die Deduplizierung von Ereignissen verarbeiten, müssen Sie nicht gewährleisten, dass das Ereignis eindeutig ist, wenn Sie einen Trigger für Workflows erstellen.
Projektübergreifende Trigger werden noch nicht unterstützt. Der Dienst, der die Ereignisse für den Trigger empfängt, muss sich im selben Google Cloud Projekt wie der Trigger befinden. Wenn Anfragen an Ihren Dienst durch Nachrichten ausgelöst werden, die in einem Pub/Sub-Thema veröffentlicht wurden, muss sich das Thema auch im selben Projekt wie der Trigger befinden. Weitere Informationen finden Sie unter Ereignisse in Google Cloud -Projekten weiterleiten.
Unabhängig davon, wo sich die VM-Instanz befindet, führen Cloud Audit-Log-Trigger für Compute Engine zu Ereignissen, die aus einer einzelnen Region stammen: us-central1. Achten Sie beim Erstellen des Triggers darauf, dass der Triggerstandort auf us-central1 oder global festgelegt ist.
Bei einigen Ereignisanbietern können Sie die Ereignisnutzlast als application/json oder application/protobuf codieren. Eine im JSON-Format formatierte Ereignisnutzlast ist größer als eine in Protobuf formatierte. Dies kann sich je nach Ereignisziel und seine Limits für die Ereignisgröße auf die Zuverlässigkeit auswirken. Wenn dieses Limit erreicht ist, wird das Ereignis gemäß den Wiederholungsmerkmalen der Transportebene von Eventarc, Pub/Sub, wiederholt.
Informationen zum Behandeln von Pub/Sub-Nachrichtenausfällen, wenn die maximale Anzahl von Wiederholungsversuchen erreicht wurde.
Wenn Sie Workflows als Ziel für einen Eventarc-Trigger verwenden, lösen Ereignisse, die größer als die maximale Argumentgröße von Workflows sind, keine Workflow-Ausführungen aus. Weitere Informationen finden Sie unter Kontingente und Limits.
Die maximale Tiefe für jeden strukturierten Logeintrag für Trigger, die Cloud-Audit-Logs verwenden, beträgt 64 Ebenen. Logereignisse, die dieses Limit überschreiten, werden verworfen und nicht von Eventarc zugestellt.
Wenn Sie zum ersten Mal einen Eventarc-Trigger in einemGoogle Cloud -Projekt erstellen, kann es zu einer Verzögerung bei der Bereitstellung des Eventarc-Dienst-Agents kommen. Dieses Problem lässt sich normalerweise durch erneutes Erstellen des Triggers beheben. Weitere Informationen finden Sie unter Fehler „Berechtigung verweigert“.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eNewly created triggers may take up to two minutes to become fully operational.\u003c/p\u003e\n"],["\u003cp\u003eDuplicate transmission of Cloud Audit Logs from certain Google Cloud sources can occur, resulting in duplicate events, so you should create triggers for fields ensuring event uniqueness.\u003c/p\u003e\n"],["\u003cp\u003eCross-project triggers are currently not supported, so the event-receiving service and the trigger must reside within the same Google Cloud project.\u003c/p\u003e\n"],["\u003cp\u003eEvents formatted in JSON are larger than those in Protobuf, potentially impacting reliability due to event size limits at the destination, and log events exceeding 64 levels are dropped when using Cloud Audit logs.\u003c/p\u003e\n"],["\u003cp\u003eProvisioning the Eventarc service agent can sometimes be delayed when creating an Eventarc trigger for the first time, which usually can be solved by reattempting the creation.\u003c/p\u003e\n"]]],[],null,["# Known issues for Eventarc Standard\n\n[Standard](/eventarc/standard/docs/overview)\n\nGemini Code Assist is only supported in\nVS Code with Gemini Code Assist + Cloud Code extension \u003cvar translate=\"no\"\u003eversion\u003c/var\u003e+.\n\nThis page lists known issues for Eventarc Standard.\n\nYou can also check for existing issues or open new issues in the\n[public issue trackers](/support/docs/issue-trackers).\n\n- **Newly created triggers can take up to two minutes to become operational.**\n\n- **If you [update a trigger](/eventarc/docs/managing-triggers#trigger-update)\n before its generated event is delivered,**\n\n the event is routed according to the previous filtering and delivered to the original destination within three days of the event generation. The new filtering is applied to events generated *after* your update.\n\n- There is known **duplicate transmission of Cloud Audit Logs from some\n Google Cloud event sources**. When duplicate logs are published, duplicate\n events are delivered to destinations. To avoid these duplicate events, you\n should create triggers for fields that ensure the event is unique.\n This applies to the following event types:\n\n - Cloud Storage (serviceName: `storage.googleapis.com`), methodName: `storage.buckets.list`\n - Compute Engine (serviceName: `compute.googleapis.com`), methodName: `beta.compute.instances.insert`\n - BigQuery (serviceName: `bigquery.googleapis.com`)\n\n Note that since Workflows handles event deduplication, you don't\n have to ensure that the event is unique when you create a trigger for\n Workflows.\n- **Cross-project triggers are not yet supported.** The service that receives\n the events for the trigger must be in the same Google Cloud project\n as the trigger. If requests to your service are triggered by messages published\n to a Pub/Sub topic, the topic must also be in the same project as the\n trigger. See\n [Route events across Google Cloud projects](/eventarc/docs/cross-project-triggers).\n\n- Regardless of where the virtual machine instance is actually located,\n **Cloud Audit Logs triggers for [Compute Engine](/eventarc/docs/reference/supported-events#compute-engine)\n result in events that originate from a single region** : `us-central1`. When\n [creating your trigger](/eventarc/standard/docs/event-providers-targets#triggers),\n ensure that the trigger location is set to either `us-central1` or `global`.\n\n- **[Direct Pub/Sub events](/eventarc/standard/docs/event-types#cloud-pubsub)\n don't include a\n [`delivery_attempt`](https://github.com/googleapis/google-cloudevents/blob/main/proto/google/events/cloud/pubsub/v1/data.proto#L45)\n field** unless the event destination is Cloud Run or\n Cloud Run functions. This might impact your\n [handling of message failures](/pubsub/docs/handling-failures).\n\n- For some event providers, you can choose to encode the event payload as\n `application/json` or `application/protobuf`. However,\n **an event payload formatted in JSON is larger than one formatted in Protobuf** ,\n and this might impact reliability depending on your event destination, and its\n limits on event size. When this limit is reached, the event is retried\n according to the [retry characteristics of Eventarc's transport\n layer, Pub/Sub](/eventarc/standard/docs/overview#event-retry-policy).\n Learn how to\n [handle Pub/Sub message failures](/pubsub/docs/handling-failures)\n if the maximum number of retries is made.\n\n- While using Workflows as a destination for an\n Eventarc trigger, **events larger than the maximum\n Workflows arguments size will fail to trigger workflow\n executions** . For more information, see\n [Quotas and limits](/workflows/quotas#resource_limit).\n\n- The maximum nested depth limit on each structured log entry for triggers\n that use Cloud Audit Logs is 64 levels. **Log events that exceed this\n limit are dropped** and not delivered by Eventarc.\n\n- When creating an Eventarc trigger for the first time in a\n Google Cloud project, there might be **a delay in provisioning the\n Eventarc service agent** . This issue can usually be resolved by\n attempting to create the trigger again. For more information, see\n [Permission denied errors](/eventarc/docs/troubleshooting#trigger-error)."]]
