Fix remote processor injection happening before dictConfig runs in configure_logging by korex-f · Pull Request #66633 · apache/airflow

korex-f · 2026-05-09T19:26:39Z

Problem

In configure_logging(), getattr(remote, "processors") was called before dictConfig() ran. dictConfig() calls _clearExistingHandlers() which closes every handler registered in logging._handlerList, including the watchtower handler built moments earlier. This caused CloudWatch/Watchtower logs to be silently dropped when using the Task SDK with remote logging.

Fix

Move the remote processor injection to after dictConfig() has run. The handler is now built into a clean logging state and cannot be killed prematurely.

Also gate the injection on not sending_to_supervisor to avoid unmasked events from the task subprocess, and add a None default to getattr to handle third-party RemoteLogIO objects missing the processors attribute.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

seanghaeli

Verified end-to-end this fixes remote logging. Thanks @korex-f this issue has been floating around for a while.

1fanwang

Thanks for addressing the comments, lgtm!

potiuk · 2026-06-09T10:44:09Z

@korex-f — A reviewer (@ashb) has requested changes on this PR, so I've removed the ready for maintainer review label — the next step is on your side. Could you address the review comments (push a fix, or reply in-thread explaining why the feedback doesn't apply)? Once addressed, re-request review from @ashb or re-mark the PR ready and it returns to the maintainer queue. Thank you.

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

korex-f · 2026-06-10T08:30:30Z

Thanks for the review, @ashb. I have addressed the requested changes, pushed the fixes, and re-requested review. Please do take another look when you have the chance.

sarvesh371 · 2026-06-11T14:23:37Z

Hey, running into this exact issue on Airflow 3.2.2 with KubernetesExecutor — task pods emit WatchtowerWarning: Received message after logging system shutdown and logs never make it to CloudWatch.

Any idea on ETA for merge and which provider version will ship the fix? Also is there any interim workaround while we wait?

Happy to test if there's a pre-release available.

jason810496

Thanks for fixing this and I verify the root case as well. The overall direction LGTM.
However, this PR touches both Task-SDK and provider.

IIRC, the current convention is separating PRs of Task-SDK and provider. So we need to make this PR Task-SDK only and raise another one for provider or vice versa.

Any idea on ETA for merge and which provider version will ship the fix? Also is there any interim workaround while we wait?

If this PR doesn't make it to the 3.3 release (since it change the Task-SDK). Then I will merge the #68779 which solve the exact issue in different direction with provider-only changes (and I verify on k8s executor setup) -> the next AWS provider version should solve this problem.

If this PR catches 3.3 release -> using Airflow 3.3 plus the next AWS provider version could solve.

korex-f · 2026-06-22T09:10:39Z

Thanks for sharing #68779 @jason810496, having read through it, I agree it's the cleaner approach to the provider side. The _closed flag correctly distinguishes dictConfig mid-task closures from genuine teardown, which is something my approach didn't handle.

Given this, I'd like to scope this PR down to task-sdk only:

Issue 1 (log.py): getattr(remote, "processors") called before dictConfig runs — Fix CloudWatch remote logging for ephemeral lifecycle executor #68779 doesn't fix this and it's the root cause
that makes Issue 2 worse
Issue 3 (supervisor.py): _close_remote_log_handler context manager to ensure the handler is flushed after process.wait() returns

That means reverting all provider changes from this PR and letting #68779 carry those.

Does that scope make sense @ashb? Happy to also drop the close() protocol addition from RemoteLogIO per your comment, since #68779 handles the provider side without needing it.

jason810496

Happy to also drop the close() protocol addition from RemoteLogIO per your comment

Yes, I think we should make this PR targeting task-sdk changes only. (more specific, only change task-sdk/src/airflow/sdk/execution_time/supervisor.py and task-sdk/src/airflow/sdk/log.py)

korex-f · 2026-07-12T10:11:21Z

Addressed all outstanding review comments:

Reverted unrelated changes in _handle_request (GetXComCount ordering and send_msg parameter style)
Restored the dropped TODO comment in _configure_logging
Used walrus operator for load_remote_log_handler() check
Added hasattr(handler, "close") guard in _close_remote_log_handler to avoid mypy error after reverting the RemoteLogIO protocol change
Reverted all provider and shared/logging changes per @jason810496 guidance, this PR now touches only supervisor.py and log.py

eladkal · 2026-07-16T18:51:57Z

Can the provider related changes be split into a dedicated PR?

korex-f · 2026-07-17T14:19:21Z

Can the provider related changes be split into a dedicated PR?

Done!
All provider and shared/logging changes were already reverted in the latest push per @jason810496's guidance. This PR now touches only task-sdk/src/airflow/sdk/execution_time/supervisor.py and task-sdk/src/airflow/sdk/log.py. The provider-side fix is being handled separately in #68779.

o-nikolas · 2026-07-17T22:15:25Z

@jason810496 and @ferruzzi, does this look good to approve/merge for y'all?

@ashb it looks like your feedback was addressed, but you "requested changes" which makes me think you saw something very serious, are you happy with this PR now?

ferruzzi · 2026-07-20T20:29:06Z

Can the provider related changes be split into a dedicated PR?

Done! All provider and shared/logging changes were already reverted in the latest push per @jason810496's guidance. This PR now touches only task-sdk/src/airflow/sdk/execution_time/supervisor.py and task-sdk/src/airflow/sdk/log.py. The provider-side fix is being handled separately in #68779.

You may not have pushed that, there are still provider changes in the current diff:

  diff --git a/providers/amazon/src/airflow/providers/amazon/aws/log/cloudwatch_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  
  diff --git a/providers/elasticsearch/src/airflow/providers/elasticsearch/log/es_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  +        if ti is None:
  +            return
  
  diff --git a/providers/opensearch/src/airflow/providers/opensearch/log/os_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  +        if ti is None:
  +            return

Edit to add: the whitespace change in supervisor.py that you said was done is also not there.

korex-f · 2026-07-21T09:47:53Z

Can the provider related changes be split into a dedicated PR?

Done! All provider and shared/logging changes were already reverted in the latest push per @jason810496's guidance. This PR now touches only task-sdk/src/airflow/sdk/execution_time/supervisor.py and task-sdk/src/airflow/sdk/log.py. The provider-side fix is being handled separately in #68779.

You may not have pushed that, there are still provider changes in the current diff:
  diff --git a/providers/amazon/src/airflow/providers/amazon/aws/log/cloudwatch_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  
  diff --git a/providers/elasticsearch/src/airflow/providers/elasticsearch/log/es_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  +        if ti is None:
  +            return
  
  diff --git a/providers/opensearch/src/airflow/providers/opensearch/log/os_task_handler.py
  -    def upload(self, path: os.PathLike | str, ti: RuntimeTI):
  +    def upload(self, path: os.PathLike | str, ti: RuntimeTI | None = None) -> None:
  +        if ti is None:
  +            return
Edit to add: the whitespace change in supervisor.py that you said was done is also not there.

Sorry for the confusion, the revert was there but spread across multiple commits, making it look like provider changes were still present in the per-commit view. The net diff against upstream/main now only touches task-sdk/src/airflow/sdk/execution_time/supervisor.py and task-sdk/src/airflow/sdk/log.py. No provider files are modified.

jason810496

Here're final nits that would appreciate be addressed before merge, thanks.

jason810496 · 2026-07-21T10:02:13Z

    def send_msg(
-        self,
-        msg: BaseModel | None,
-        request_id: int,
-        error: ErrorResponse | None = None,
-        **dump_opts,
+        self, msg: BaseModel | None, request_id: int, error: ErrorResponse | None = None, **dump_opts
    ):


Would prefer not change this part.

jason810496 · 2026-07-21T10:06:41Z

+        if (remote_handler := load_remote_log_handler()) is not None:
+            _close_remote_log_handler(remote_handler)
+
+        if log_file_descriptor is not None:
+            with contextlib.suppress(Exception):
+                log_file_descriptor.close()


Should we switch the order of closing log_file_descriptor and the remote log handler? IIUC, closing the file first then flush the renaming logs to remote IO makes more sense to me.

jason810496 · 2026-07-21T10:07:43Z

+def _close_remote_log_handler(handler: RemoteLogIO) -> None:
+    """
+    Close the remote log handler explicitly after all task log messages have been drained from the subprocess pipe.
+
+    Called after process.wait() returns, before process exit triggers
+    logging.shutdown(). This ensures the remote handler's internal batch
+    queue is flushed before the process tears down. For example, the AWS
+    CloudWatch logger will emit:
+
+        WatchtowerWarning: "Received message after logging system shutdown"
+
+    if this is not done before process exit.
+    """
+    try:
+        if hasattr(handler, "close"):
+            handler.close()
+    except Exception:
+        log.warning("Failed to close remote log handler", exc_info=True)


Suggested change

def _close_remote_log_handler(handler: RemoteLogIO) -> None:

"""

Close the remote log handler explicitly after all task log messages have been drained from the subprocess pipe.

Called after process.wait() returns, before process exit triggers

logging.shutdown(). This ensures the remote handler's internal batch

queue is flushed before the process tears down. For example, the AWS

CloudWatch logger will emit:

WatchtowerWarning: "Received message after logging system shutdown"

if this is not done before process exit.

"""

try:

if hasattr(handler, "close"):

handler.close()

except Exception:

log.warning("Failed to close remote log handler", exc_info=True)

jason810496 · 2026-07-21T10:09:00Z

+
+        # TODO: Use logging providers to handle the chunked upload for us etc.
+        if (remote_handler := load_remote_log_handler()) is not None:
+            _close_remote_log_handler(remote_handler)


The scope and the purpose of the function is small and clear enough, we don't need the additional function for this. I'd like to collapse it back.

Suggested change

_close_remote_log_handler(remote_handler)

try:

if hasattr(handler, "close"):

handler.close()

except Exception:

log.warning("Failed to close remote log handler", exc_info=True)

kaxil · 2026-07-21T19:15:59Z

Picking up on @o-nikolas's merge question -- I think this needs a second look at scope before it goes in, because a fair bit of it landed via other PRs while this was open:

Fix CloudWatch remote logging for ephemeral lifecycle executor #68779 (merged) made the CloudWatch RemoteLogIO self-healing: the handler property rebuilds if dictConfig closed it mid-task, and upload() now calls close() to flush pending events. That covers the Cloudwatch remote logging does not work for ECS Executor #66475 symptom at the provider layer.
Upload task logs even when final state update fails #67935 (merged) moved _upload_logs() into a finally after update_task_state_if_needed(), so logs upload even when the state update raises.
Remote logging fix #68370 (merged) fixed the cached-None-connection case so the worker can upload at all.

Given that, the supervisor.py side here (explicit _close_remote_log_handler on teardown) now overlaps with _upload_logs() → upload() → close(), which already runs on the state-update error path after #67935. The log.py reorder (build the handler after dictConfig) is the one piece not on main, but with the self-healing handler it's no longer a live drop -- more of a cleaner-root-cause argument.

@korex-f -- is there a failure mode left that the three merged PRs don't cover? If the log.py reorder is the remaining value, it may be worth narrowing this to just that (with a test); otherwise it looks mostly superseded now. Not trying to discount the work here, just want to make sure we're not re-landing something.

korex-f · 2026-07-22T08:49:57Z

Picking up on @o-nikolas's merge question -- I think this needs a second look at scope before it goes in, because a fair bit of it landed via other PRs while this was open:
* **[Fix CloudWatch remote logging for ephemeral lifecycle executor #68779](https://github.com/apache/airflow/pull/68779)** (merged) made the CloudWatch `RemoteLogIO` self-healing: the `handler` property rebuilds if `dictConfig` closed it mid-task, and `upload()` now calls `close()` to flush pending events. That covers the [Cloudwatch remote logging does not work for ECS Executor #66475](https://github.com/apache/airflow/issues/66475) symptom at the provider layer.

* **[Upload task logs even when final state update fails #67935](https://github.com/apache/airflow/pull/67935)** (merged) moved `_upload_logs()` into a `finally` after `update_task_state_if_needed()`, so logs upload even when the state update raises.

* **[Remote logging fix #68370](https://github.com/apache/airflow/pull/68370)** (merged) fixed the cached-`None`-connection case so the worker can upload at all.
Given that, the supervisor.py side here (explicit _close_remote_log_handler on teardown) now overlaps with _upload_logs() → upload() → close(), which already runs on the state-update error path after #67935. The log.py reorder (build the handler after dictConfig) is the one piece not on main, but with the self-healing handler it's no longer a live drop -- more of a cleaner-root-cause argument.

@korex-f -- is there a failure mode left that the three merged PRs don't cover? If the log.py reorder is the remaining value, it may be worth narrowing this to just that (with a test); otherwise it looks mostly superseded now. Not trying to discount the work here, just want to make sure we're not re-landing something.

Thanks for the detailed audit @kaxil — really helpful context.

You're right that #68779, #67935, and #68370 together cover the provider-layer symptom. Looking at what's left:

log.py reorder (Bug 1): getattr(remote, "processors") was called before dictConfig ran, which meant dictConfig's _clearExistingHandlers closed the just-built watchtower handler before any task log was emitted. With #68779's self-healing property this is no longer a live drop, the handler rebuilds on next access, but the reorder is still the correct root-cause fix and removes the need for the rebuild in the first place. It's a cleaner argument even if it's no longer strictly necessary for correctness.

supervisor.py _close_remote_log_handler: You're right this now overlaps with upload() → close() from #67935/#68779. I'm happy to drop the supervisor.py changes entirely if you think log.py alone is worth keeping, or close the whole PR if you think it's fully superseded. I'd rather do the right thing for the codebase than land something redundant.

What would you prefer?

jason810496

Thank you for the update.

is there a failure mode left that the three merged PRs don't cover?

Yes log.py reorder (Bug 1): getattr(remote, "processors") was called before dictConfig ran, which meant dictConfig's _clearExistingHandlers closed the just-built watchtower handler before any task log was emitted. statement is correct.

I'd like to keep the only the log.py changes as that is the key point to resolve the unexpected .close on logging handler. The supervisors.py change is more "nice to have" but it might introduce further regression. Let's keep the change minimal if possible, thanks.

korex-f · 2026-07-27T09:04:20Z

Thank you for the update.

is there a failure mode left that the three merged PRs don't cover?

Yes log.py reorder (Bug 1): getattr(remote, "processors") was called before dictConfig ran, which meant dictConfig's _clearExistingHandlers closed the just-built watchtower handler before any task log was emitted. statement is correct.

I'd like to keep the only the log.py changes as that is the key point to resolve the unexpected .close on logging handler. The supervisors.py change is more "nice to have" but it might introduce further regression. Let's keep the change minimal if possible, thanks.

Thanks for the clarity. Reverting all supervisor.py changes now, this PR will only contain the log.py reorder (Bug 1). supervisor.py can be revisited in a follow-up if needed.

jason810496

Hi @korex-f,

Thanks for follow-up on this.
We need to do the following items before merge.

Add unit test to exercise the patch itself
Fix the CI failure
Rephrase the PR title and the description

Thanks.

korex-f · 2026-08-01T04:35:01Z

Hi @korex-f,

Thanks for follow-up on this. We need to do the following items before merge.
* Add unit test to exercise the patch itself

* Fix the CI failure

* Rephrase the PR title and the description
Thanks.

Added a regression test in test_log.py that verifies load_remote_log_handler() is called only after the inner configure_logging() (dictConfig) returns. The CI failure in test_inject_parent_job_info_with_resume_on_retry is unrelated, it's a Glue operator test making a real network call that times out, last touched in #64513. Happy to re-trigger CI to confirm it's a flake.

…nfigure_logging In configure_logging(), getattr(remote, 'processors') was called before dictConfig() ran. dictConfig() calls _clearExistingHandlers() which closes every handler in logging._handlerList — including the remote handler built moments earlier. This caused CloudWatch/Watchtower logs to be silently dropped when using the Task SDK with remote logging on ECS/Kubernetes workers. Fix: move the remote processor injection to after dictConfig() has run via a second structlog.configure() call. Also gate on not sending_to_supervisor to avoid unmasked events from the task subprocess, and add a None default to getattr() to handle third-party RemoteLogIO objects. Provider-side fix: apache#68779 Closes apache#66475

…nfigure_logging In configure_logging(), getattr(remote, 'processors') was called before dictConfig() ran. dictConfig() calls _clearExistingHandlers() which closes every handler in logging._handlerList — including the remote handler built moments earlier. This caused CloudWatch/Watchtower logs to be silently dropped when using the Task SDK with remote logging on ECS/Kubernetes workers. Fix: move the remote processor injection to after dictConfig() has run via a second structlog.configure() call. Also gate on not sending_to_supervisor to avoid unmasked events from the task subprocess, and add a None default to getattr() to handle third-party RemoteLogIO objects. Closes apache#66475

jason810496

#70938 - fix the OpenAI provider CI failure. Rebasing on top of the latest main should fix. Thanks.

jason810496

LGTM overall now, thanks.

jason810496 · 2026-08-02T07:33:31Z

+    # Accessing remote.processors triggers creation of the remote handler
+    # via a cached_property. The configure_logging() call below runs dictConfig() internally,


We don't need to mention the cached_property workaround anymore. Since this PR address the root cause.

Suggested change

# Accessing remote.processors triggers creation of the remote handler

# via a cached_property. The configure_logging() call below runs dictConfig() internally,

# The configure_logging() call below runs dictConfig() internally,

jason810496 · 2026-08-02T07:38:42Z

+        assert events[0]["log_level"] == "warning"
+        assert events[0]["ti_id"] == str(ti.id)
+        assert events[0]["exc_info"] is boom


nit: How about asserting with events[0] == {"log_level": ..., "ti_id": ...} style?

jason810496 · 2026-08-02T07:39:37Z

+        assert events[0]["log_level"] == "warning"
+        assert events[0]["ti_id"] == str(ti.id)
+        assert events[0]["log_relative_path"] == relative.as_posix()
+        assert events[0]["exc_info"] is boom


nit: Ditto.

korex-f requested review from amoghrajesh, ashb, kaxil, o-nikolas and potiuk as code owners May 9, 2026 19:26

boring-cyborg Bot added area:logging area:providers area:task-sdk provider:amazon AWS/Amazon - related issues labels May 9, 2026

potiuk added the ready for maintainer review Set after triaging when all criteria pass. label May 11, 2026

1fanwang reviewed May 12, 2026

View reviewed changes

Comment thread task-sdk/src/airflow/sdk/execution_time/supervisor.py Outdated

o-nikolas mentioned this pull request May 12, 2026

Cloudwatch remote logging does not work for ECS Executor #66475

Closed

2 tasks

o-nikolas reviewed May 12, 2026

View reviewed changes

o-nikolas approved these changes May 15, 2026

View reviewed changes

ferruzzi reviewed May 26, 2026

View reviewed changes

Comment thread providers/amazon/src/airflow/providers/amazon/aws/log/cloudwatch_task_handler.py Outdated

ashb requested changes Jun 2, 2026

View reviewed changes

seanghaeli approved these changes Jun 2, 2026

View reviewed changes

korex-f force-pushed the fix/remote-log-handler-premature-close branch from 904f1ea to ff723d1 Compare June 6, 2026 05:51

1fanwang approved these changes Jun 6, 2026

View reviewed changes

korex-f force-pushed the fix/remote-log-handler-premature-close branch from ff723d1 to 93a67a7 Compare June 7, 2026 00:44

potiuk removed the ready for maintainer review Set after triaging when all criteria pass. label Jun 9, 2026

korex-f requested a review from ashb June 10, 2026 08:24

potiuk added the ready for maintainer review Set after triaging when all criteria pass. label Jun 17, 2026

jason810496 mentioned this pull request Jun 20, 2026

Fix CloudWatch remote logging for ephemeral lifecycle executor #68779

Merged

jason810496 reviewed Jun 20, 2026

View reviewed changes

potiuk assigned korex-f Jul 2, 2026

jason810496 reviewed Jul 3, 2026

View reviewed changes

vincbeck mentioned this pull request Jul 7, 2026

Status of testing Providers that were prepared on July 07, 2026 #69562

Closed

75 tasks

korex-f changed the title ~~Fix: CloudWatch/Watchtower logs dropped in Task SDK due to handler lifetime bugs~~ Fix CloudWatch/Watchtower logs dropped in Task SDK due to handler lifetime bugs Jul 12, 2026

korex-f force-pushed the fix/remote-log-handler-premature-close branch from 921eb9d to f6d0f20 Compare July 21, 2026 09:46

jason810496 reviewed Jul 21, 2026

View reviewed changes

jason810496 reviewed Jul 24, 2026

View reviewed changes

jason810496 reviewed Jul 29, 2026

View reviewed changes

korex-f changed the title ~~Fix CloudWatch/Watchtower logs dropped in Task SDK due to handler lifetime bugs~~ Fix remote processor injection happening before dictConfig runs in configure_logging Jul 29, 2026

korex-f force-pushed the fix/remote-log-handler-premature-close branch from 608b35f to ec31091 Compare August 1, 2026 09:43

jason810496 reviewed Aug 2, 2026

View reviewed changes

		# Accessing remote.processors triggers creation of the remote handler
		# via a cached_property. The configure_logging() call below runs dictConfig() internally,

	# Accessing remote.processors triggers creation of the remote handler
	# via a cached_property. The configure_logging() call below runs dictConfig() internally,
	# The configure_logging() call below runs dictConfig() internally,

Uh oh!

Conversation

korex-f commented May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Related

Uh oh!

chris-stetter commented May 11, 2026

Uh oh!

korex-f commented May 11, 2026

Uh oh!

Uh oh!

o-nikolas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

korex-f commented May 13, 2026

Uh oh!

o-nikolas left a comment

Choose a reason for hiding this comment

Uh oh!

potiuk commented May 18, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

seanghaeli left a comment

Choose a reason for hiding this comment

Uh oh!

1fanwang left a comment

Choose a reason for hiding this comment

Uh oh!

potiuk commented Jun 9, 2026

Uh oh!

korex-f commented Jun 10, 2026

Uh oh!

sarvesh371 commented Jun 11, 2026

Uh oh!

jason810496 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

korex-f commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jason810496 left a comment

Choose a reason for hiding this comment

Uh oh!

korex-f commented Jul 12, 2026

Uh oh!

eladkal commented Jul 16, 2026

Uh oh!

korex-f commented Jul 17, 2026

Uh oh!

o-nikolas commented Jul 17, 2026

Uh oh!

ferruzzi commented Jul 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

korex-f commented Jul 21, 2026

Uh oh!

jason810496 left a comment

Choose a reason for hiding this comment

Uh oh!

korex-f commented May 9, 2026 •

edited

Loading

jason810496 left a comment •

edited

Loading

korex-f commented Jun 22, 2026 •

edited

Loading

ferruzzi commented Jul 20, 2026 •

edited

Loading

korex-f commented Aug 1, 2026 •

edited

Loading

jason810496 Aug 2, 2026 •

edited

Loading