We faced Issues during Migration to Isolated Worker Process
Dear Microsoft Support Team,
We are in the process of migrating our application from the in-process model to Azure Functions Isolated Worker, following all official Microsoft guidelines.
While we have updated the configuration as suggested, we are currently facing two major issues:
- [Singleton] Attribute No Longer Supported
Our application logic heavily relies on the [Singleton] attribute, which is no longer supported in the isolated worker model.
This poses a significant challenge in terms of:
Ensuring single-instance execution for certain critical operations
Preserving the same behavior without major architectural overhaul
We are exploring alternatives like:
Service Bus sessions for message ordering and instance locking
Distributed locking
We’d appreciate it if you could provide Microsoft-recommended patterns or best practices to safely replace the [Singleton] attribute and maintain the original singleton behavior within the isolated worker model.
- Logging Gaps in Isolated Worker Model
We are also experiencing serious gaps in telemetry (Application Insights) since the migration:
operation_name is missing for many traces, exceptions, dependencies, and custom events
Custom dimensions are intermittently dropped or missing entirely
These issues were not present in the in-process model
This telemetry is critical to our business for monitoring, debugging, and custom workbook dashboards.
Could you advise on:
How to preserve full log fidelity (including operation_name and custom dimensions) in the isolated worker model?
Whether there's a recommended approach or configuration for bridging this telemetry gap?
We’d really appreciate your guidance on these issues, as they’re essential for ensuring feature parity and observability in the new hosting model.