Documentation for App Tasks?

[techdragon]

The documentation for App Tasks (https://docs.servicestack.net/releases/v6_3#app-tasks) is basically missing.... Its mentioned in the 6.3 release notes only, but the feature is also really simple so its probably got all the documentation it needs however I just need some slightly more complete examples to "get it". Has anyone else used it (other than the little bit of use I see it getting in the migration tools)... this is probably just my python background where code is more explicit so its easier to see what's going on, so my apology if this seems like a simple question.

[mythz]

Yeah there's not much more to it, what's the use-case you're trying to achieve?

[techdragon]

I managed to work it out with a little more time, but I do think it could do with a dedicated page in the documentation. Unless you read old release notes you might miss that the feature exists.

Also the documentation appears incorrect. It says that it exits before starting the HTTP stack, but now I've started using it, every time I've used it I have logs to the contrary.

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.

Is this a usage problem (which would also point to a need for more specific documentation) or a bug?

[mythz]

Yup good idea, I've created a new page for AppTasks we can add to later at:

https://docs.servicestack.net/app-tasks

[techdragon]

@mythz A missing detail in the documentation is how to run this with production builds (like production container images ready for deployment) as the dotnet run examples won't work in this case.

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'run' does not exist.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

and people will need to use dotnet <dll_name> --AppTasks=<program_specific_arguments>

Also should I open an issue report for the HTTP server starting up when running App Tasks, as this contradicts their documented behaviour? From the first paragraphs of the docs. (Emphasis mine)

App Tasks let you run one-off tasks with the full context of your App but without the overhead of maintaining a separate .exe with duplicated App configuration. With App Tasks you can run your ASP .NET Core App, run the specified Tasks then exit before launching its HTTP Server.

[mythz]

Our GitHub Actions for building / deploying our https://jamstacks.net templates have been upgraded to run migrations which is being run as a separate container in Docker Compose:

https://github.com/NetCoreTemplates/blazor-tailwind/blob/main/.deploy/docker-compose-template.yml#L22

  ${APP_NAME}-migration:
    image: ghcr.io/${IMAGE_REPO}:${RELEASE_VERSION}
    restart: "no"
    profiles:
      - migration
    command: --AppTasks=migrate
    volumes:
      - ${APP_NAME}-mydb:/app/App_Data

as part of release.yml which should cause deployment to fail if the container returns a failed exit code:

https://github.com/NetCoreTemplates/blazor-tailwind/blob/main/.github/workflows/release.yml#L175

docker compose -f ~/.deploy/${{ github.event.repository.name }}-docker-compose.yml up ${{ github.event.repository.name }}-migration --exit-code-from ${{ github.event.repository.name }}-migration

Not seeing the issue with the docs which says what your CI could use AppTasks to do, not how to do it. You're welcome to propose better phrasing by editing app-tasks.md.

[techdragon]

Ah, I'm talking about running App Tasks stand alone after a build was completed separately. In this particular case, all builds happen in a separate AWS account which publishes the docker containers into the organisation's container registry. So the differences in the CI workflow are definitely responsible for some of the use case differences here.

And I was asking about the HTTP server while testing the App Task feature I built a small demo for myself and when I ran it I saw the HTTP server try and start up (debugging in Jetbrains Rider with multiple tasks failed saying the HTTP server port was already in use) and I was not sure if It was a bug or just me using it wrong since I'm new to ASP.Net and wasn't sure if I had accidentally pulled in something else into my test/demo that was causing the ASP.Net HTTP server to try and start.

[techdragon]

@mythz Following up on the conversation about the HTTP server startup issue in Discord yesterday, I've checked the relative positioning of app.Run(); and AppTasks.Register(...); and they are in the "correct order", with Register(...); being used before Run();. This is a snippet from a demo/test codebase that I've confirmed demonstrates the behaviour.

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    AppTasks.Register("echoClient", args => { sqsechoclient.Sender.Test(args); });
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
    app.UseHttpsRedirection();
}
app.UseServiceStack(new AppHost());
app.Run(async context => context.Response.Redirect("/metadata"));

app.Run();

And the resulting log output from this code is:

info: ServiceStack.ServiceStackHost[0]
      Initializing Application sqsechoclient took 430.7602ms. No errors detected.
warn: ServiceStack.Aws.Sqs.SqsMqServer[0]
      Cannot start SqsMqServer MQ Server with no Message Handlers registered, ignoring.
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app/
Running AppTask 'echoClient'...

[mythz]

Where AppTasks.Register() is called doesn't matter, they just need to registered before AppTasks are run with AppTasks.Run() which if you're not running it explicitly in Program.cs or a Modular Startup as done in the Configure.Db.Migrations.cs example will be run by ServiceStack which is only able to do after the ASP.NET Core Host has started.

If you don't want the WebHost to start, run it either in a Modular Startup or before the WebHost is run, i.e:

AppTasks.Run();
app.Run();