Add missing indexes for call stack columns in V3_7 migrations

[Copilot]

The V3_7 migrations added three new columns for activity execution call stack tracking but did not create indexes on them. These columns (SchedulingActivityExecutionId, SchedulingActivityId, SchedulingWorkflowInstanceId) are used for chain traversal queries and filtering, requiring indexes to avoid table scans.

Changes

• EF Core Configuration: Added index definitions for the three scheduling columns in Configurations.cs
• SQLite/PostgreSQL/Oracle: Added CreateIndex/DropIndex operations in Up/Down methods
• SQL Server: Created columns as nvarchar(450) (matching existing indexed ID columns) with indexes
• MySQL: Created columns as varchar(255) (matching existing indexed ID columns) with indexes

All column types align with existing schema patterns for indexed identifier columns in their respective providers.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Pull request overview

This PR adds database indexes to three call stack tracking columns (SchedulingActivityExecutionId, SchedulingActivityId, SchedulingWorkflowInstanceId) that were introduced in the V3_7 migration. The indexes are necessary to optimize chain traversal queries and filtering operations.

Changes:

• Added EF Core index configurations for three scheduling columns in the ActivityExecutionRecord entity
• Modified V3_7 migrations across all database providers to include index creation
• Changed column types to be index-compatible (nvarchar(450) for SQL Server, varchar(255) for MySQL)

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/modules/Elsa.Persistence.EFCore/Modules/Runtime/Configurations.cs	Added three index definitions for scheduling columns using consistent naming pattern
src/modules/Elsa.Persistence.EFCore.SqlServer/Migrations/Runtime/20260122123023_V3_7.cs	Changed column types from nvarchar(max) to nvarchar(450) and added indexes in Up method; added DropIndex operations in Down method
src/modules/Elsa.Persistence.EFCore.MySql/Migrations/Runtime/20260122123013_V3_7.cs	Changed column types from longtext to varchar(255) and added indexes in Up method; added DropIndex operations in Down method
src/modules/Elsa.Persistence.EFCore.Sqlite/Migrations/Runtime/20260122123040_V3_7.cs	Added CreateIndex operations for TEXT columns in Up method; added DropIndex operations in Down method
src/modules/Elsa.Persistence.EFCore.PostgreSql/Migrations/Runtime/20260122123049_V3_7.cs	Added CreateIndex operations for text columns in Up method; added DropIndex operations in Down method
src/modules/Elsa.Persistence.EFCore.Oracle/Migrations/Runtime/20260122123056_V3_7.cs	Added CreateIndex operations for NVARCHAR2(2000) columns in Up method; added DropIndex operations in Down method

[Copilot]

This PR modifies an existing V3_7 migration that may have already been deployed to production systems. If users have already run the original V3_7 migration (dated January 22, 2026), their databases will have these columns with incompatible types for indexing (nvarchar(max) instead of nvarchar(450)). Running migrations again won't fix existing columns since EF Core tracks which migrations have been applied.

Consider one of these approaches:

1. If V3_7 has NOT been released yet, this change is fine.
2. If V3_7 HAS been released, create a new migration (e.g., V3_7_1 or V3_8) that uses AlterColumn operations to change the column types and then adds the indexes.
3. Add explicit SQL commands in the Up method to alter the column type if it already exists with the wrong type.

[Copilot]

Similar to SQL Server, this modifies an existing V3_7 migration that may have already been deployed. If users have already run the original V3_7 migration, their databases will have these columns with longtext type instead of varchar(255), making them incompatible with indexing.

Consider one of these approaches:

1. If V3_7 has NOT been released yet, this change is fine.
2. If V3_7 HAS been released, create a new migration (e.g., V3_7_1 or V3_8) that uses AlterColumn operations to change the column types and then adds the indexes.
3. Add explicit SQL commands in the Up method to alter the column type if it already exists with the wrong type.

Suggested change

	// Ensure the scheduling columns use an indexable type even if they were previously created as LONGTEXT.
	var tableName = string.IsNullOrWhiteSpace(_schema.Schema)
	? "`ActivityExecutionRecords`"
	: $"`{_schema.Schema}`.`ActivityExecutionRecords`";
	migrationBuilder.Sql($"""
	ALTER TABLE {tableName}
	MODIFY COLUMN `SchedulingActivityExecutionId` varchar(255) NULL,
	MODIFY COLUMN `SchedulingActivityId` varchar(255) NULL,
	MODIFY COLUMN `SchedulingWorkflowInstanceId` varchar(255) NULL;
	""");