Fixes issue #7631 with wrong archiver lookup

[PADRESH]

Calling the GetVisibilityArchiver and GetHistoryArchiver functions causes errors when the internal frontend is enabled. We should either check the current configuration or simply call these functions with the InternalFrontendService parameter if an error occurs.

What changed?

Added fallback logic for archiver retrieval in namespace_handler.go and workflow_handler.go to handle cases when the initial call fails.

Why?

When the internal frontend is enabled, all visibility and history containers are registered under the InternalFrontendService key. However, some calls in namespace_handler.go and workflow_handler.go still attempt to retrieve archivers using the FrontendService key.

How did you test it?

• [ v] built
• [v ] run locally and tested manually
• [v ] covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

If the archival configuration is incorrect, the system takes additional time to fail/recognize the error.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[yycptt]

Thanks for the contribution @PADRESH!

It looks like the issue is caused by namespaceHandler and workflowHandler on frontend hardcoded to use primitives.FrontendService when getting the archiver implementation.

Instead of adding fallback logic, I think we should remove those hardcoded service name and plumb through the actual serviceName to those two components. Similar to what RegisterBootstrapContainer is doing.
primitives.ServiceName type is already available in the fx graph and in HandlerProvider in service/frontend/fx.go, so only NewWorkflowHandler and newNamespaceHandler needs to be updated to take in an additional ServiceName argument.

cc @dnr who has more context on internal frontend.

[PADRESH]

@yycptt, thank you for the suggestions. I've committed the changes and tested them locally (kubernetes).

[PADRESH]

@yycptt, @dnr What do you think about my last commit? What else can I do to promote the request?

[dnr]

This is okay for what it is, but the problem is really that the archival provider/bootstrap/fx stuff is kind of a mess. There's no reason that it should take a service name at all, each fx app gets its own archiverProvider so it will only ever be called with one service name. The "Bootstrap" structs should just be parameter lists or fx.In structs. If you'd like to tackle refactoring this all, that would be even better than this fix, since it would remove a lot of unnecessary code.

Though I think we can accept this in the short term if it fixes the problem.

I ran CI for this PR... note the failures and please fix.

[dnr]

This is okay for what it is, but the problem is really that the archival provider/bootstrap/fx stuff is kind of a mess. There's no reason that it should take a service name at all, each fx app gets its own archiverProvider so it will only ever be called with one service name. The "Bootstrap" structs should just be parameter lists or fx.In structs.

I just tried using an AI tool to do this refactoring and came up with #7766

@PADRESH Could you check to see if that one solves the problem?

[PADRESH]

@dnr Yes. Problem solved.