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

Teardown conflict with task scheduler #106

Open
vintagesucks opened this issue May 15, 2024 · 4 comments
Open

Teardown conflict with task scheduler #106

vintagesucks opened this issue May 15, 2024 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@vintagesucks
Copy link
Contributor

Hi! I noticed that my "Sites" navigation on Forge contained some sites that should have been deleted already.

grafik

In fact, the site overview for that server no longer even shows the site, indicating that something has happened:

grafik

This happens on every teardown, but only when I include FORGE_JOB_SCHEDULER=true in my environment.

To narrow it down, I reduced the pipeline in TearDownCommand to this:

->through([
  FindServer::class,
  FindSiteOrFail::class,
  RemoveTaskScheduler::class,
  DestroySite::class,
])

Only when RemoveTaskScheduler is included here does the above bug occur. I think Forge is silently failing to actually remove the site if the scheduled job is still being removed. If I add something like sleep(10) before DestroySite, everything is deleted as expected:

->through([
  FindServer::class,
  FindSiteOrFail::class,
  RemoveTaskScheduler::class,
  function (ForgeService $service, Closure $next) {
    sleep(10);
    return $next($service);
  },
  DestroySite::class,
])

I am not sure if this is a bug in the Forge API/SDK or if Harbor is somehow supposed to wait for the job to actually be deleted, but this is currently resulting in many orphaned sites on my Forge server.

Complete environment from my local test:

SUBDOMAIN_NAME="test"
FORGE_DOMAIN="<removed>"
FORGE_GIT_BRANCH="main"
FORGE_GIT_REPOSITORY="<removed>"
FORGE_JOB_SCHEDULER=true
FORGE_PHP_VERSION="php82"
FORGE_SERVER="<removed>"
FORGE_TOKEN="<removed>"
FORGE_DEPLOY_SCRIPT="cd $FORGE_SITE_PATH"

Command I can use to reproduce the problem locally:

php ./harbor provision && php ./harbor teardown

This will return Environment teardown successful! All provisioned resources have been removed. and the site is partially removed from some parts of Forge, but remains in the site navigation and, more importantly, on the actual server.

@shawnhooper
Copy link
Contributor

I've had this same problem. I haven't yet dug as deeply as @vintagesucks has into it. I have had to login to the server a few times and delete sites manually to clear up space. Sometimes in the file system directly, as they were already removed from the Sites dashboard.

Maybe related, I've also seen my GitHub account run of out deployment keys.

@Hannsre
Copy link

Hannsre commented May 21, 2024

I've come across this as well. A new PR Site will be spawned without issues usually, but on teardown it won't be removed completely.
Haven't dug as deep yet as well, but I can't see any remnants of the preview Site in the forge Dashboard. But if I check via the Forge API, the removed site is still there in Status removing:

    "site": {
        "id": (removed),
        "server_id": (removed),
        "name": "pr-Id.example.com",
        "aliases": [],
        "directory": "/public",
        "wildcards": false,
        "status": "removing",

I can delete this site using the forge API manually then, but this shouldn't be necessary.

I can also confirm that setting FORGE_JOB_SCHEDULER to False will solve this issue for me.

Edit/Addition: I just noticed that for me this only happens in a PHP 8.3 environment. We also use Harbor for a different Project that's currently on PHP 8.2 which does not show the same issue. Here Teardown works as intended with FORGE_JOB_SCHEDULER set to true.

@samshupac
Copy link

I'm also experiencing this same issue.
This solution of setting FORGE_JOB_SCHEDULER: false isn't ideal as it means the temporary environments we create can't be used to test features fully.

FYI @mehrancodes

@mehrancodes mehrancodes added the bug Something isn't working label Jul 10, 2024
@RealMrHex
Copy link
Collaborator

Hey @vintagesucks, thanks for your report and explanations.
I'm working on this issue and ill update u all asap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants