Data Migration - The ConnectionString property has not been initialized #15290
Comments
|
Can you log the exception in your Try/Catch? Can you show the actual migration that invokes your custom |
|
I am also noticing this when upgrading 1.8.2 to main.
|
|
@MikeAlhayek can you try to point to the previous SqlClient version locally (with the security advisory) |
|
@sebastienros I added the following into my project. But not sure if it has any affect since none of my projects directly depend on the SqlClient. Also, the problem is not consistent. I think it happens due to slow responding "like time out" but not really sure. I'll see if I can get the root cause locally. |
Sorry for the delay. The code concerning the call of the migrations is the following: private async Task InitializeIndexes()
{
try
{
await SensorIndex.WithSchemaBuilder(SchemaBuilder);
}
catch (Exception e)
{
logger.LogError(e, "Error creating SensorIndex");
}
try
{
await AverageSensorIndex.WithSchemaBuilder(SchemaBuilder);
}
catch (Exception e)
{
logger.LogError(e, "Error creating AverageSensorIndex");
}
try
{
await AddressIndex.WithSchemaBuilder(SchemaBuilder);
}
catch (Exception e)
{
logger.LogError(e, "Error creating AddressIndex");
}
}This is subsequently called in one of the migration steps: public async Task<int> UpdateFrom89Async()
{
await migrationFactory.CreateAsync<ChangeTextForTooltip>().MigrateAsync();
await InitializeIndexes();
return 90;
}Regarding the theorized timeout this could also be the case because the system is rather underpowered (it's a dev stage). This would also explain why this isn't happening on my local device |
|
Could it be a bug in the driver that when a connection is failing it's still returned to the pool in an incorrect state. I have seen issues related in the Microsoft.Data.SqlClient repository recently. Something to try also is to add some reconnection properties to the connection string if that's supported. |
|
Retargeting to 2.0 since this is a regression from 1.7.x. We see the same exception (may or may not be the same issue, stack trace is naturally different) but only under /Admin/Workflows/Types. It's thrown every time, even after a fresh setup without any actual Workflow Types. With Azure SQL. |
Merged
|
I have no local repro (neither with a local SQL Server nor with a remote Azure one) on v1.8.3 BTW, only prod (hosted in Azure, Azure SQL). |
|
@Piedone i also cannot reproduce it locally. In fact, it’s not consistent in production so it hard to encounter it. If you are able to, can you try @sebastienros theory #15290 (comment) on your production? So in your solution force using an older version of SqlClient package and see if that fixes it. Hopefully you can test it out since it seems to happens more in your environment |
|
For us it's 100% consistent in prod, so yeah, that's a good starting point. I'll check. |
|
I localized the issue to this line in a custom module of ours. As you can see, it's a simple I added to the root web project, but this didn't fix the issue. I've then taken v1.8.2 and changed only the removal of the I've also taken the other changes from your PR to make sure that it still works, and it does. So, IMO no further fixes necessary and this can be closed. |
|
@Piedone FYI, not important but in the EmailQuotaService all the methods updating the quota instance also call SaveAsync but it's not necessary since it's either coming from the database or being created and then tracked. Which means that any change on this instance will be detected and saved automatically when SaveChagnesAsync() is invoked. But there are no side effects to call SaveAsync() since it will do a lookup, find the instance, and skip, it's just one extra async call for nothing. |
|
Ah indeed, thank you! |
|
So, as confirmed by @MikeAlhayek, the Workflows issue is indeed fixed. And this one here looks like an issue with the custom code. So, closing it now; please reopen if still applicable. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I migrated from 1.7.x to 1.8.2 and fixed all the warnings concerning the obsolete content type and part migration steps. The system is hosted in a docker container on azure. After deploying, the system freezes and times out. Analyizing the stack trace I got this:
Besides that the error in my log says the following:
NOTE: The connection string IS SET.
Apparently something is going wrong when initalizing the indexes. Here is the example code for the failing sensor index:
As you can see, I already wrapped the initialization into a trycatch statement. In the past we got exceptions telling us that the index already exists. Since all tenants already exist and have migrated to the new indexes I summarized the updates for each index creation into one method (without harming the order of the migrations).
To Reproduce
Steps to reproduce the behavior:
Expected behavior
On one hand I would expect the index logic to check if the index already exists and only if that's not the case it should create the index tables. Besides that I want to know where the error is originating and what I can do to prevent it from happening.
Screenshots
The text was updated successfully, but these errors were encountered: