Me again.
I was using the example code up until the Exercise #1 recap. When I go to start the worker as shown in the video, I get this error message:
➜ go run worker/main.go
2024/04/09 16:13:37 INFO No logger configured for temporal client. Created default one.
panic: expected first argument to be workflow.Context but found string
Probably doing something stupid again too. Any tips would be greatly appreciated.
Scott
Ok. I figured it out.
The “app” needs to be this:
package app
import "go.temporal.io/sdk/workflow"
func GreetSomeone(ctx workflow.Context, name string) (string, error) {
return "Hello " + name + "!", nil
}
I grabbed the code at the beginning and not the end of the transcript. So, my bad again.
Scott
But, I am now using the actual code from the edu-101-go-code repo and I’m getting this:
Which I was also getting with my “cut and paste” code.
How to possibly troubleshoot this? Workflow isn’t showing in the UI either. (self-hosted in k8s).
Scott
Make sure that the worker that contains workflow code is running and that it listens on exactly the same task queue name as the one used to start the workflow.
Hi Maxim,
I have the worker running in another terminal.
The other strange thing is, I don’t see the workflow in the UI, when I kick it off with temporal workflow start. 
Scott
Something else I ran into earlier was I got an error about the default namespace not being available. So I went (trying out if it was intuitive) with the CLI help to try and add the default namespace. I got the default namespace added, well, I got the error to go away, but maybe I didn’t set up the namespace properly?
Namespaces seem to be an important part of running workflows, aren’t they? Maybe a section about them in the tutorial could be advantageous?
Scott
I’ve also have the issue of being able to delete and update namespaces. Deleting fails with a “unable to delete namespace: context deadline exceeded” error.
If I use the CLI temporal operator namespace update command, it says the update was successful, but nothing changes.
This is the pod error I found, when deleting:
{“level”:“error”,“ts”:“2024-04-10T07:50:39.041Z”,“msg”:“service failures”,“operation”:“OperatorDeleteNamespace”,“wf-namespace”:“my-namespace”,“error”:“System Workflow with WorkflowId temporal-sys-delete-namespace-workflow and RunId 1ce52ca3-bb36-488f-9515-d0c65678f6db returned an error: context canceled”,“logging-call-at”:“telemetry.go:341”,“stacktrace”:“go.temporal.io/server/common/log.(*zapLogger).Error\n\t/home/builder/temporal/common/log/zap_logger.go:156\ngo.temporal.io/server/common/rpc/interceptor.(*TelemetryInterceptor).handleError\n\t/home/builder/temporal/common/rpc/interceptor/telemetry.go:341\ngo.temporal.io/server/common/rpc/interceptor.(*TelemetryInterceptor).UnaryIntercept\n\t/home/builder/temporal/common/rpc/interceptor/telemetry.go:174\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/service/frontend.(*RedirectionInterceptor).Intercept\n\t/home/builder/temporal/service/frontend/redirection_interceptor.go:180\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/common/authorization.(*interceptor).Interceptor\n\t/home/builder/temporal/common/authorization/interceptor.go:158\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/common/metrics.NewServerMetricsContextInjectorInterceptor.func1\n\t/home/builder/temporal/common/metrics/grpc.go:66\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc.UnaryServerInterceptor.func1\n\t/go/pkg/mod/go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc@v0.42.0/interceptor.go:344\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/common/rpc/interceptor.(*NamespaceLogInterceptor).Intercept\n\t/home/builder/temporal/common/rpc/interceptor/namespace_logger.go:84\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/common/rpc/interceptor.(*NamespaceValidatorInterceptor).NamespaceValidateIntercept\n\t/home/builder/temporal/common/rpc/interceptor/namespace_validator.go:111\ngoogle.golang.org/grpc.getChainUnaryHandler.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1195\ngo.temporal.io/server/common/rpc.ServiceErrorInterceptor\n\t/home/builder/temporal/common/rpc/grpc.go:145\ngoogle.golang.org/grpc.chainUnaryInterceptors.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1186\ngo.temporal.io/api/operatorservice/v1._OperatorService_DeleteNamespace_Handler\n\t/go/pkg/mod/go.temporal.io/api@v1.24.1-0.20231003165936-bb03061759c8/operatorservice/v1/service.pb.go:320\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1376\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:1753\ngoogle.golang.org/grpc.(*Server).serveStreams.func1.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.58.2/server.go:998”}
Scott
And strange enough, I see this in postgres.
And if I describe the namespace, the result is showing it was deleted.
Scott
Hi Scott,
What Maxim was saying in post #4 is that the Task Queue is specified in two places. One is the Worker (in this case, I can see from your screenshot in post #5 that your Worker uses the Task Queue named “default”). The other is the TaskQueue field in the StartWorkflowOptions used by the code that uses a Temporal Client to submit the execution request (here’s an example of that from a later exercise in the Temporal 101 with Go course).
If the Task Queue name isn’t the same in both places, the Workflow Execution does not progress and it will look exactly as depicted in your screenshot from post #2. The WorkflowExecutionStarted and WorkflowTaskScheduled events you see here do not involve the Worker. Task Queues are created dynamically, so submitting the Workflow to one Task Queue and having the Worker listen on a different one does not result in an error; it just creates two different Task Queues. In this case, the Worker is listening on a different Task Queue than the one used to start the execution, so the Worker will never see the queued Task (i.e., the one instructing it to run the Workflow code) and therefore does not do any work related to this execution.
When you run a Temporal Cluster via the CLI (as described in the course here), the default Namespace is created automatically. That’s also the case when running one using our docker-compose configuration (as described here). Since a k8s-based cluster is not a supported configuration for this training course, I’d strongly recommend following the instructions for running the Temporal Cluster via the CLI if you want to work on the exercises locally. To be clear, you absolutely can run a self-hosted Temporal Cluster on Kubernetes and many of our users do so in production, but trying to do that while learning Temporal adds unnecessary complication.
Running Temporal with Kubernetes is not my personal area of expertise, so if you have follow-up questions about that, I’d recommend starting a new thread and using the kubernetes tag on your post and/or asking in the #kubernetes channel on our community Slack..
Isn’t the task queue “greeting-tasks”? That’s how it is defined in the worker, I thought.
The namespace is “default”.
Thing is, my whole development setup is now inside a k8s cluster. 
So, I’m sort of stuck for now with making sure I get things running properly in k8s.
I’ll check over with the Slack community about my k8s setup. I want to go through it again anyways. Maybe (probably), I did something wrong. Thanks for the help!!!
Scott
You’re exactly right. It’s using the default Namespace and the greeting-tasks Task Queue.
I was writing some code related to Namespaces just before my reply to you and my eye went right to the Namespace. I’m really sorry for the confusion.
If the Workflow doesn’t progress beyond the initial WorkflowTaskScheduled Event, as seen in post #2, it strongly suggests that the Worker is either not running or that it’s not polling the same Task Queue used to start the Workflow Execution. So, if you’re still having that problem, I’d recommend verifying the code (or CLI command) used to start the Workflow.
I think I’ve got something set up wrong in the cluster. Checking more frontend logs, I’m getting connection errors from postgres and other connection problems. Also, I thought I had set up elasticsearch properly, but it seems it isn’t being used. Once I figure all this out, I’ll more than likely be back with some more nooby questions. 
Thanks again for the support!! Much appreciated!
Scott
