Logs in golang are not displayed in the console (Windows)

[walterdl]

Bug Report

I'm facing a weird behavior with golang and serverless-offline on windows; any log produced with the standard packages log and fmt are not shown in the console and some of them are sent as the HTTP response when the lambda is triggered as an HTTP endpoint.

Current Behavior

• Invokations to any logging method from the log standard package end up in the HTTP response. Methods like log.Print or log.Println. The logs are not shown in the console.
• Invocations to any logging method from the fmt standard package causes a 502 HTTP response. The logs are not shown in the console.

Sample Code

• file: serverless.yml

  service: golang-sls-offline-windows-bug
  
  frameworkVersion: '3'
  
  provider:
    name: aws
    runtime: go1.x
    stage: ${opt:stage, 'dev'}
    region: us-west-2
  
  functions:
    myService:
      handler: ./services/my_service.go
      events:
        - http:
            path: /
            method: get
  plugins:
    - serverless-offline
  
  package:
    individually: true

• file: services/my_service.go

  package main
  
  import (
    "context"
    "log"
  
    "github.com/aws/aws-lambda-go/events"
  )
  
  func HandleRequest(context.Context, events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {
    log.Print("This is printed as the http response :(") // Change this with fmt.Println and you will have a 502 🙁
  
    // This HTTP result is never sent
    return events.APIGatewayProxyResponse{
      StatusCode: 200,
      Body:       `{"message": "Hello serverless world"}`,
      Headers: map[string]string{
        "Content-Type": "application/json",
      },
    }, nil
  }
  
  func main() {
    fmt.Println("Hello, world!")
  }

Expected behavior/code

The logs from log.Print and fmt.Println should be shown in the console. They should not be shown as the HTTP response or break the service by returning 502 Status code.

Environment

• serverless version: 3.7.1
• serverless-offline version: ^8.5.0
• node.js version: 14.19.0
• OS: Windows 11

optional, if you are using any of the following frameworks to invoke handlers

• go version: 1.7

Possible Solution

Additional context/Screenshots

• The log.Print being showed in Postman as the HTTP response:
• The fmt.Println causing 502 status code:

[pgrzesik]

Hey @walterdl - thanks for reporting.

Hey @icarus-sullivan - do you think would be able to take a look at it? I'm not very experienced with Golang so it might be hard for me to take a deeper look into it.

[icarus-sullivan]

@pgrzesik I have an update to the mock-lambda go implementation that needs to be merged which might fix this issue. Will hopefully have some time this weekend to take a look.

[pgrzesik]

Thanks a lot @icarus-sullivan 🙇

[icarus-sullivan]

@walterdl @pgrzesik Hey folks, ran some tests locally. Seems log is being construed as stderr in the response even though it's technically not an error. I'm going to test some more scenario's where an actual error occurs in the lambda to see what occurs. Worst case scenario we merge all stderr and stdout when parsing the payload and output it as expected.

[icarus-sullivan]

@pgrzesik PR here https://github.com/dherault/serverless-offline/pull/1355

[youg9203]

Any update on this? I'm facing the same issue on Mac OS, running serverless offline and unable to print the logs in the console.

    "serverless": "3.22.0",
    "serverless-apigateway-service-proxy": "2.2.0",
    "serverless-apigw-binary": "0.4.4",
    "serverless-cloudformation-sub-variables": "0.2.1",
    "serverless-deployment-bucket": "1.6.0",
    "serverless-domain-manager": "6.1.0",
    "serverless-dynamodb-local": "0.2.40",
    "serverless-git-info": "1.2.3",
    "serverless-offline": "11.0.3",
    "serverless-plugin-conditional-functions": "1.0.7",
    "serverless-plugin-ifelse": "1.0.7",
    "serverless-prune-plugin": "2.0.1",
    "serverless-s3-cleaner": "2.0.1"

Additionally GoLang bersion go version: go1.19.3 darwin/amd64

[abdullateef97]

@youg9203 please I don't know if you found a work around for this, @walterdl as well

[abdullateef97]

@pgrzesik please the bug is still existing

[abdullateef97]

@DorianMazur please take a look here