Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data Api Builder: graphql endpoint not working immediate after startup. #485

Open
RobertK66 opened this issue Feb 18, 2025 · 3 comments
Open

Comments

@RobertK66
Copy link

Describe the bug

I am using aspire hosting with a Data API builder service and one (WPF) Client. The client is configured to WaitFor() the DAB service to be available:

            var dab = builder.AddDataAPIBuilder("dab", 5006, "..\\dab_paptex\\dab-config.json")
                             .WithEnvironment("dab-connection-string", connection)
                             .WithLifetime(ContainerLifetime.Persistent)
                             .WithImageTag("1.3.19");

            builder.AddProject<Projects.WpfApp1>("client")
                   .WithReference(dab)
                   .WaitFor(dab);

My client uses the graphql endpoint on startup and tries to load some data when the MainWindow is loaded.
I had to introduce an extra delay here to make this work! A minimum of 1000ms delay is needed to get a correct answer from the graphql endpoint!

When accessing without a delay i get

   "An error occurred while sending the request. The response ended prematurely. (ResponseEnded)"

The log shows that in both cases (with and without delay) the URL is correctly discovered, but without delay the exception is thrown from the PostAsync() method of the HTTPClient:

System.Net.Http.HttpClient.GqlClient.LogicalHandler: Information: Start processing HTTP request POST http://dab/graphql
'WpfApp1.exe' (CoreCLR: clrhost): Loaded 'D:\dev\gina\vssln\Paptex\PaptexSqlDab\WpfApp1\bin\Debug\net9.0-windows\Microsoft.Extensions.Features.dll'. Symbol loading disabled by Include/Exclude setting.
System.Net.Http.HttpClient.GqlClient.ClientHandler: Information: Sending HTTP request POST http://localhost:5006/graphql
'WpfApp1.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\9.0.2\System.Net.Sockets.dll'. Symbol loading disabled by Include/Exclude setting.
'WpfApp1.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\9.0.2\System.Net.NameResolution.dll'. Symbol loading disabled by Include/Exclude setting.
Exception thrown: 'System.Net.Http.HttpIOException' in System.Net.Http.dll
Exception thrown: 'System.Net.Http.HttpRequestException' in System.Net.Http.dll

Regression

No response

Steps to reproduce

1. Make a solution with Aspire hosting for a DAB service and a client app
2. Configure the client project with "WaitFor(dab)" to be sure the service is started when the client app gets started.
3. On Startup of client app make immediate use of the graphql endpoint of the DAB service.

Expected behavior

It should work without additional delay needed on the client side.

Screenshots

No response

IDE and version

VS 2022

IDE version

Version 17.12.5

Nuget packages

"Aspire.Hosting.AppHost" Version="9.0.0"
"CommunityToolkit.Aspire.Hosting.Azure.DataApiBuilder" Version="9.1.0"

Additional context

I am not sure if this is the right repos to raise this issue (in the end this is about the startup behavior of the Data API builder!) but I think the issue is not so urgent for production use of the DAB, where the services should run prior to clients anyway....

What I also tried to workaround for better developer experience when using this aspire integration:

  • keep the dab service running with WithLifetime(ContainerLifetime.Persistent) but even with an explicit image tag the container gets recreated on the next startup.

Is there another way of making delays between services in Aspire? This would help to avoid having the delay in the application startup code of the client!

Help us help you

Yes, but only if others can assist

@aaronpowell
Copy link
Member

I think this is somewhat limited by the need to implement #190 as in the current form the WaitFor only waits for the container to start and not for the service inside the container to be started.

@RobertK66
Copy link
Author

RobertK66 commented Feb 19, 2025

Ok, having a 'real health check' would be the ultimate solution for this.

But on the level of 'developer workaround' I wonder why the WithLifetime(ContainerLifetime.Persistent) does not come to rescue here. Did I miss something to make this work? The container is kept running after shutdown of the debug session. But on startup there is always a new one created, even when nothing is changed in the config/configfile for it.

@aaronpowell
Copy link
Member

Yes, it should stay around. Are you seeing the container being deleted when you stop the app host?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants