v0.24.3

What's Changed

• use components for calls between envelope and weavelet (this allows support for grpc + multiple languages)
• bug fixes based on customer feedback
• improve documentation
• improve the health mechanism
• new blog posts
• add shutdown method per component
• reduce the number of buckets for metrics

v0.22.0

To use v0.22 of Service Weaver, run the following commands in the root of your application's module:

go get github.com/ServiceWeaver/[email protected]                # Update the weaver module.
go install github.com/ServiceWeaver/weaver/cmd/[email protected] # Update the weaver command line tool.

Runtime Graph API Improvements

A Service Weaver application is composed of a directed acyclic graph of components. When you build a Service Weaver application, the component call graph is embedded into the binary itself. In v0.22.0, we improved the API of the bin.ReadComponentGraph function, which extracts and returns the component call graph. Now, bin.ReadComponentGraph returns a fully-fledged graph data structure, which has some helpful graph algorithms that let you do things like iterate over the graph in topological order.

• Add a graph library and use it to represent the component call-graph. by @spetrovic77 in #638
• Add DFS utilities to the graph library. by @spetrovic77 in #642

Example Chat App Improvements

The chat app is an example Service Weaver application that is backed by a MySQL database. v0.22.0 includes instructions on how to run the application locally against a MySQL instance running in Docker, and how to run the application on Kubernetes against a MySQL instance running in the Kubernetes cluster. If you want to learn how to write and deploy a database-backed Service Weaver application, the chat app is a great place to look.

• Added local MySQL instructions for chat app. by @mwhittaker in #639
• Use docker containers to test the chat app. by @mwhittaker in #641
• Added instructions to run chat app on Kubernetes. by @mwhittaker in #645

Bank of Anthos Example App

We ported Bank of Anthos to Service Weaver.

• Ported Bank of Anthos. by @mwhittaker in #438

Bug Fixes

• Avoid 'weaver multi' zombie main components. by @mwhittaker in #644

New Contributors

• @bobfuru made their first contribution in #652

Full Changelog: v0.21.2...v0.22.0

v0.21

To use v0.21 of Service Weaver, run the following commands in the root of your application's module:

go get github.com/ServiceWeaver/[email protected]                # Update the weaver module.
go install github.com/ServiceWeaver/weaver/cmd/[email protected] # Update the weaver command line tool.

Automatic Method Retries

Components are the core abstraction of Service Weaver. Two components can be co-located in the same process or distributed across multiple machines. When a component calls a method on a co-located component, the method call is performed as a regular Go method call. When a component calls a method on a component hosted on another machine, the method call is executed as a remote procedure call (RPC).

The network is not reliable, so RPCs can sometimes fail to execute properly. Starting in v0.21, the Service Weaver runtime automatically retries these RPCs for you. The retries are done with jittered exponential back-off, and retries are stopped when the provided context.Context is cancelled. Note that a method call that executes successfully and returns a non-nil error is not retried. Only method calls that fail to execute properly (e.g., because of a network failure) are retried.

Note that in some cases, it may not be safe to arbitrarily retry a method call. In these cases, you can mark a method as NotRetriable, and Service Weaver will not retry it for you.

type Foo interface {
    A(context.Context) error
}

var _ weaver.NotRetriable = Foo.A

weavertests will also spuriously retry method calls to catch any cases where you forget to mark a non-retriable method as non-retriable.

See #570 and #575 for details.

Prettier Logs

v0.21 introduces some small tweaks to our logging pretty printer. See #577, #578, and #579 for details.

Bug Fixes

• Verify registered listeners when starting the app. by @spetrovic77 in #561
• Make sure the callgraph always includes a node for weaver.Main. by @spetrovic77 in #584
• Fixed missing env bug in single deployments. by @mwhittaker in #581

New Contributors

• @giautm made their first contribution in #594

Full Changelog: v0.20.0...v0.21.0

v0.20.0

To use v0.20.0 of Service Weaver, run the following commands in the root of your application's module:

go get github.com/ServiceWeaver/[email protected]                # Update the weaver module.
go install github.com/ServiceWeaver/weaver/cmd/[email protected] # Update the weaver command line tool.

Requiring Go 1.21

Service Weaver now requires Go 1.21. This allows us to use the new slog package. See #520 for details.

Deployer API Changes

We made some small simplifications to the deployer API in v0.20.0. The SingleProcess field was removed from EnvelopeInfo (#521), and the Pid field was removed from WeaveletInfo (#522). The InternalPort field in EnvelopeInfo was replaced with InternalAddress (#526). These changes shouldn't affect Service Weaver applications. Only deployer implementations need to be updated.

Codegen Changes

weaver generate now generates new reflection-based stubs (#481). These stubs will be used in our ongoing work on implementing deterministic simulation.

Bug Fixes

• Added unit tests for remote weavelet. by @mwhittaker in #528
• Fixed RemoteWeavelet UpdateRoutingInfo bugs. by @mwhittaker in #529
• Fixed bugs in RemoteWeavelet UpdateComponents. by @mwhittaker in #530
• Replaced os.Exit with RemoteWeavelet Wait method. by @mwhittaker in #531
• Extended test deployer to spawn multiple weavelets by @mwhittaker in #532
• Added distributed RemoteWeavelet failure tests. by @mwhittaker in #533
• Removed phantom "main" from weaver single status. by @mwhittaker in #537
• Fixed period (".") app name bug. by @mwhittaker in #541
• Clarify "weaver generate" version error message. by @mwhittaker in #542

New Contributors

• @Deleplace made their first contribution in #543

Full Changelog: v0.19.0...v0.20.0

v0.19.0

To use v0.19.0 of Service Weaver, run the following commands in the root of your application's module:

go get github.com/ServiceWeaver/[email protected]                # Update the weaver module.
go install github.com/ServiceWeaver/weaver/cmd/[email protected] # Update the weaver command line tool.

Logging

Service Weaver v0.19.0 introduces a small breaking change to the logging API. The Logger method on weaver.Implements now has a context.Context argument. Here's an example:

type Adder interface {
    Add(context.Context, int, int) (int, error) 
}

type adder struct {
    weaver.Implements[Adder]
}

func (a *adder) Add(ctx context.Context, x, y int) (int, error) {
    // NOTE that the Logger method now takes a context. 
    a.Logger(ctx).Debug("Add", "x", x, "y", y) 
    return x + y, nil
}

The logger returned by Logger now includes labels for any OpenTelemetry trace and span ids that are stored in the provided context. This allows you to correlate logs and traces, which makes debugging much easier. We also slightly changed how logs are pretty printed:

Before	After

See #495, #496, and #512 for details.

RPC Health Checking

We added more sophisticated health checking to our RPC implementation, which is used to remotely execute component method calls. With this change, fewer method calls should fail when a component replica fails. See #498 for details.

Validations

We try to detect invalid Service Weaver applications at compile time (see https://serviceweaver.dev/blog/weaver_generate.html, for example), but some checks have to be done at runtime. We have introduced a number of new validation checks in v0.19.0. Specifically, we check that every component has been registered correctly (#500) and that all listener names are valid (#501). We also report more error messages when things go wrong to make it easier to debug issues (#493).

Full Changelog: v0.18.0...v0.19.0

v0.18.0

Custom Error Values

Recall that the final return value of every component method must be an error:

// A calculator component. Note that the final return value of every method is an error.
type Calculator interface {
    Add(context.Context, int, int) (int, error)
    Subtract(context.Context, int, int) (int, error)
    Multiply(context.Context, int, int) (int, error)
}

Before v0.18.0, these error values were encoded and decoded using a custom protocol that did not preserve the type of the error. For example, if you returned a custom error value from a component method (e.g., return &customError{}), the caller of the method would not receive an error of the same type.

In v0.18.0, any errors that embed weaver.AutoMarshal will be properly encoded and decoded. Here's a simple example:

type customError struct {
    weaver.AutoMarshal
    msg string
}

Errors that don't embed weaver.AutoMarshal will continue to use our custom protocol.

See #456, #458, and #457 for details.

Tracing

weaver.InstrumentHandler now automatically implements time-based trace sampling for you. We also optimized how we store and query traces on disk, and we now garbage collect old traces. We also improved the tracing UI in weaver single dashboard and weaver multi dashboard. See #450, #459, #460, #464, #465, #472, and #478 for details

weaver.Instance Removed

The weaver.Instance interface was removed (#455). It was not being used and was obsoleted by weaver.InstanceOf[T].

Bug Fixes

• Previously, the logs produced by weaver multi logs --format=json did not include log entry attributes. This was fixed in #470.

Internals

Most of the core weaver implementation has moved to the private internal/weaver package. This has no effect on the users of Service Weaver, but does enable some internal cleanups. For example, we split the weavelet implementation into two separate and much simpler weavelets, one for go run and one for all other deployers. For those interested in learning more about the internals of Service Weaver, this change should make it much easier to understand what's going on under the hood. See #461 and #466 for details.

Full Changelog: v0.17.0...v0.18.0

v0.17.0

New and Improved weaver version

Before v0.17.0, weaver version was both complicated and a bit broken:

$ weaver version
weaver (devel)
target: linux/amd64
commit: ?
deployer API: 0.13.0
codegen API: 0.11.0

In v0.17.0, weaver version is simpler and works again:

$ weaver version
weaver v0.17.0 linux/amd64

See #421 for details.

Local Metrics and Faster Metrics

Service Weaver automatically creates and maintains metrics for component method calls. For example, serviceweaver_method_count counts the number of method calls, and serviceweaver_method_latency_micros measures the latency of method calls. Before v0.17.0, these metrics were maintained for remote method calls but not local calls. In v0.17.0, these metrics are maintained for all method calls, local and remote (#429). We also optimized metrics to make method calls even faster (#440).

Better Mismatched Version Errors

Before v0.17.0, when you ran into versioning issues, you would see an error like this:

You used 'weaver generate' codegen version 0.17.0, but you built your
code with an incompatible weaver module version. Try upgrading 'weaver
generate' and re-running it.

Now, you see a much more helpful error message that looks like this:

ERROR: You generated this file with 'weaver generate' v0.17.0. The generated code is incompatible 
with the version of the github.com/ServiceWeaver/weaver module that you're using. The weaver 
module version can be found in your go.mod file or by running the following command.

    go list -m github.com/ServiceWeaver/weaver

We recommend updating the weaver module and the 'weaver generate' command by
running the following.

    go get github.com/ServiceWeaver/weaver@latest
    go install github.com/ServiceWeaver/weaver/cmd/weaver@latest

Then, re-run 'weaver generate' and re-build your code. If the problem persists,
please file an issue at https://github.com/ServiceWeaver/weaver/issues.

See #431 and #432 for details.

weaver.AutoMarshal in Router Keys

Router keys are now allowed to contain weaver.AutoMarhsal. See #415 for details.

Bug Fixes

• Move "DO NOT EDIT" line before package clause. by @mwhittaker in #412
• Fixed main-only bug in multi deployer. by @mwhittaker in #422

New Contributors

• @zailic made their first contribution in #415
• @miroswan made their first contribution in #416
• @tiennv1997 made their first contribution in #424

Full Changelog: v0.16.1...v0.17.0

v0.16.0

New weaver.Run API

In v0.15.0, the main component had a Main method that was automatically invoked by weaver.Run. For v0.16.0, we removed this Main method. weaver.Run now receives a lambda argument with a pointer to the main component implementation as an argument (#409). Here's an example.

type app struct {
    weaver.Implements[weaver.Main]
}

func main() {
    err := weaver.Run(context.Background(), func (_ context.Context, app *app) error  {
        app.Logger().Info("Hello, World!")
        return nil
    })
    if err != nil {
        log.Fatal(err)
    }
}

New weavertest API

Recall that the Test and Benchmark methods of a weavertest.Runner receive a lambda with component interface arguments (#406):

// Test the Foo and Bar components.
runner.Test(t, func(t *testing.T, foo Foo, bar Bar) {...})

In v0.16.0, these lambdas can also receive pointers to component implementations:

// Test the foo and bar component implementations.
runner.Test(t, func(t *testing.T, foo *foo, bar *bar) {...})

The Test and Benchmark methods no longer automatically run the Main method, which is obvious considering we also removed the Main method (#405)! This makes the new weavertest API essential for testing the HTTP server exported by a main component. See examples/chat/server_test.go for an example.

Listener Config

Listener names are now case sensitive (#404).

Bug Fixes

v0.16.0 also fixes bugs in the onlineboutique app (#393) and in the output of weaver version (#399).

Full Changelog: v0.15.0...v0.16.0