An after-update Opportunity trigger writes to related records, and that write re-fires the same trigger inside the same transaction. Without a re-entrancy guard the same record is handled several times: duplicate notifications, doubled rollups, and SOQL and DML limits burned on work that was already done. The fix is a static Set of Id named processedOpportunityIds, declared above the method, because a static variable is initialized once per transaction and keeps its value across every invocation inside that transaction, which is exactly the lifetime a recursion guard needs.

Write a method that processes a list of Opportunities exactly once per transaction. If opps is null or empty, return an empty List<String> immediately. Otherwise walk opps in order. For each record, if its Id is not null and processedOpportunityIds already contains that Id, skip it. Otherwise append its Name to the result, and if its Id is not null, add that Id to processedOpportunityIds. A record with a null Id was never saved and cannot be identified, so it is always processed and is never added to the guard, because a Set of Id can hold null and contains(null) would return true afterward, making every later unsaved record look like it was already handled. Names are returned in input order.

Examples: