Possible bug: eventing.log error on missing `log_level`

Eventing
1

Hi!

I just detected a possible bug, but I don’t really know where to post it, so here it is.

I’m using CB 6.0.0-beta on Docker (Windows host).

When creating an eventing function through the REST API endpoint POST /api/v1/functions, I’m providing the following body:

{
  "appname": "testFn_1535782832544",
  "appcode": "function OnUpdate(doc, meta) {\n\n    // Check if we're processing a timer task\n    if (doc.doc_type !== 'eventing_integration_test_model') {\n        return;\n    }\n\n    doc.processed = true;\n\n}\n",
  "depcfg": {
    "Buckets": [
      {
        "alias": "bucket_test",
        "bucket_name": "XXXXXX_test"
      }
    ],
    "metadata_bucket": "XXXXXX_test_eventing_metadata",
    "source_bucket": "XXXXXX_test"
  },
  "settings": {
    "dcp_stream_boundary": "from_now",
    "deployment_status": true,
    "processing_status": true,
    "execution_timeout": 60
  }
}

I’m seeing in the eventing.log Couchbase log file this entry:

interface conversion: interface {} is nil, not string, stacktrace: goroutine 509 [running]:
github.com/couchbase/eventing/suptree.(*Supervisor).runService.func1.1(0xc42012c1c0, 0x1)
	/home/couchbase/jenkins/workspace/couchbase-server-unix/goproj/src/github.com/couchbase/eventing/suptree/supervisor.go:392 +0xbc
panic(0xbea900, 0xc420088180)
	/home/couchbase/.cbdepscache/exploded/x86_64/go-1.10.3/go/src/runtime/panic.go:502 +0x229
github.com/couchbase/eventing/producer.(*Producer).parseDepcfg(0xc42021c700, 0xd2e6c8, 0xc42021c700)
	/home/couchbase/jenkins/workspace/couchbase-server-unix/goproj/src/github.com/couchbase/eventing/producer/depcfg_parser.go:324 +0x3706
github.com/couchbase/eventing/producer.(*Producer).Serve(0xc42021c700)
	/home/couchbase/jenkins/workspace/couchbase-server-unix/goproj/src/github.com/couchbase/eventing/producer/producer.go:89 +0x70
github.com/couchbase/eventing/suptree.(*Supervisor).runService.func1(0xc42012c1c0, 0xfc589de200000001, 0xdb4e80, 0xc42021c700)
	/home/couchbase/jenkins/workspace/couchbase-server-unix/goproj/src/github.com/couchbase/eventing/suptree/supervisor.go:398 +0x63
created by github.com/couchbase/eventing/suptree.(*Supervisor).runService
	/home/couchbase/jenkins/workspace/couchbase-server-unix/goproj/src/github.com/couchbase/eventing/suptree/supervisor.go:388 +0x5b

It probably all goes back to this row, which is an unchecked cast:

logLevel := settings["log_level"].(string)

I’m clearly missing the log_level entry in the body of the function, but I assume this should be a checked cast, or filtered out at the API level.

This bug is causing an eventing function to:

  • Be marked as deployed.
  • Be constantly marked as “boostrapping” in an infinite loop, impossible do undeploy and delete.

Thank you,
Alberto

1 Like
2

Eventing expects user to provide all required fields while creating a function using REST API.
Please create a function from UI and then export it, and use it as a template, and then change the fields as needed. This way you can avoid missing required fields for a function to deploy.
Nevertheless, the issue seen in this case is valid as eventing should check missing fields.
We are tracking this issue via https://issues.couchbase.com/browse/MB-31146

Thanks for finding this issue and reporting it.

1 Like
3

You’re welcome :smile:

Please create a function from UI and then export it, and use it as a template, and then change the fields as needed

I was actually wondering if there’s more documentation available regarding the function configuration. Apart from a function definition ( https://github.com/couchbase/eventing/blob/master/common/common.go#L206 ) and its parsing ( https://github.com/couchbase/eventing/blob/master/producer/depcfg_parser.go#L17 ), I wasn’t able to find a clear explanation for all function settings flags.

Thank you :slight_smile:

4

Function configuration is discussed at - https://developer.couchbase.com/documentation/server/6.0/eventing/eventing-adding-function.html

Thank you.

5

Hi @cmaster11

Thanks for reporting the bug. Fix is getting validated by test suite.

Regarding explanation for setting flags, we’re adding up a readme within eventing repo. That later our documentation team could use and capture in official docs.

Thanks,
Abhishek

6

Sounds good! I’ll happily wait for it!

7

P.s. you’re all doing an amazing job!

8

Hi,

Fix is merged. Requested QE folks to do bit more testing with more combinations for payloads against /api/v1 rest endpoints.
Regarding documentation for settings parameters - https://github.com/couchbase/eventing/blob/master/docs/settings-60.md. Intention is keep updating it when new settings get added.

Thanks.

9

Oooh, that is SO nice! :smiley: thanks a lot!

I was wondering, do the timers work with a polling method? I found this constant around: https://github.com/couchbase/eventing/blob/d91453b8111e2bb6029cdf7cb2195ea85dc2b736/timers/timer_store.go#L20

Is it like the minimum resolution of the polling or am I talking about something else? If it’s the resolution, is it going to stay a constant/not configurable parameter?

Thanks,
Alberto

10

That setting right now controls the interval for spacing out timers. If you create timer for 12:00:01, it gets created for 12:00:07. Timer scan routine would scan for 12:00:00 and then would scan for 12:00:07.

Reason why we haven’t made it configurable is because if timers initially are created with spacing of 7s and then later if user changes resolution to 3s - this would lead to missed firing of timer events. (This is something that we would face once we start support for pause/resume of function execution - right only deploy/undeploy is supported)

We could make it configurable per function, but it would still be tied to each deploy/undeploy cycle i.e. with deploy we would create timers with resolution R1 and on undeploy all timers that are yet to fire would get cleaned up. On next deploy operation, user could choose resolution R2 if they want to.

Another side-effect of lowering down resolution would be more frequent polling in metadata bucket, leading to more bucket ops on an idle cluster.

Thanks.

11

Makes sense for the polling amount of course. For more sensible intervals I guess it’s more appropriate that apps handle timers themselves, especially on a scale (with many of these timers to be run).

Thanks, this info is definitely worth knowing when planning how to use Couchbase timers!

Alberto