log uncaught errors in handlers (#264)

## Why

having o11y into why procedures died unexpectedly is good, we used to
have this but lost it in the migration

## What changed

re-log errors in procs

<!-- Describe the changes you made in this pull request or pointers for
the reviewer -->

## Versioning

- [ ] Breaking protocol change
- [ ] Breaking ts/js API change

<!-- Kind reminder to add tests and updated documentation if needed -->

package.json

@@ -1,7 +1,7 @@
 {
   "name": "@replit/river",
   "description": "It's like tRPC but... with JSON Schema Support, duplex streaming and support for service multiplexing. Transport agnostic!",
-  "version": "0.200.1",
+  "version": "0.200.2",
   "type": "module",
   "exports": {
     ".": {

router/server.ts

@@ -505,6 +505,20 @@ class RiverServer<Services extends AnyServiceSchemaMap>
       span.recordException(err instanceof Error ? err : new Error(errorMsg));
       span.setStatus({ code: SpanStatusCode.ERROR });
 
+      this.log?.error(
+        `${serviceName}.${procedureName} handler threw an uncaught error`,
+        {
+          ...loggingMetadata,
+          transportMessage: {
+            procedureName,
+            serviceName,
+          },
+          extras: {
+            error: errorMsg,
+          },
+        },
+      );
+
       onServerCancel({
         code: UNCAUGHT_ERROR_CODE,
         message: errorMsg,
@@ -518,10 +532,7 @@ class RiverServer<Services extends AnyServiceSchemaMap>
     } else if (procedure.type === 'rpc' || procedure.type === 'subscription') {
       // Though things can work just fine if they eventually follow up with a stream
       // control message with a close bit set, it's an unusual client implementation!
-      this.log?.warn('sent an init without a stream close', {
-        ...loggingMetadata,
-        clientId: this.transport.clientId,
-      });
+      this.log?.warn('sent an init without a stream close', loggingMetadata);
     }
 
     const handlerContext: ProcedureHandlerContext<object> = {