old configs don't work anymore, consider releasing a major version due to breaking changes?

[wzrdtales]

We just noticed there was some movement after an eternity :p

however the latest changes break things quite horribly. We get tons of errors and crashes, so I guess you should consider releasing a version 4 unless this wasn't intended:

Here a crash example:

GubuError: Validation failed for object "{log:silent,actcache:{activ..." because the properties "actcache, seneca" are not allowed

[wzrdtales]

btw. the new typescript version is quite slower than the old js version. so this switch comes with a downgrade :/

[wzrdtales]

@rjrodger

[rjrodger]

@wzrdtales this is a bug - thanks! 3.x should remain compatible - will update

[rjrodger]

@wzrdtales any details on the specific things that are slower?

[rjrodger]

@wzrdtales we are preparing for Seneca 4.x - please DM on twitter or linkedin would like to make sure this is mostly painless for you but will need to understand what you are using

[wzrdtales]

pinged you on linkedin, but you can just hit me a mail as well its public on my github profile

[wzrdtales]

and slower: everything. dramatically. In Process calls are 44+% (40k vs 62k before per process) slower. Remote as well (7k vs 11k per process). We hard forked seneca for now should we want to make hotfixes, but that should be just a temporary thing. We have applications that hit those limits of requests per second pretty hard, so that is a show stopper for us and naturally we went back to status quo. Just tested with the latest version, same same, still significantly slower.

[rjrodger]

which version did you fork on?

[wzrdtales]

https://github.com/WizardTales/seneca-ng

[tswaters]

Dug through the code a little bit, this message is returned by "gubu" which seems to do message validation now.

I found it can be disabled by applying the following legacy options:

legacy: { rules: true },

Relevant comments from the code,

// If false, use Gubu for message validation.
rules: false,
// If false, use Gubu for option validation (including plugin defaults)
options: true,

I'd think "rules" should default to "true" for a non-breaking change?

[tswaters]

I can also confirm at least one performance issue. Looks like this was introduced between 3.16.0 => 3.17.0

Our tests use a beforeEach hook to initialize seneca, add a bunch of plugins and call seneca.ready(done)

$ npm i seneca@3.16.0 && time npm test
real    0m2.566s
user    0m3.059s
sys 0m0.224s

$ npm i seneca@3.17.0 && time npm test
real    0m19.922s
user    0m6.289s
sys 0m0.388s

$ npm i seneca@latest && time npm test
real    0m20.610s
user    0m7.340s
sys 0m0.373s

The beforeEach hooks go from ~10ms to ~150ms (measured with console.time & console.timeEnd). The actual tests themselves don't seem affected and complete sub 10ms. Going to need to do some stress tests to see if runtime is affected... (in the midst of updating an ancient seneca version to latest and found this). 3.29.0 is comparable to 3.17.0

[wzrdtales]

will conduct another performance test with the latest changes soon @rjrodger

[wzrdtales]

Things are getting worse actually, i just checked in here again, we have forked seneca since it started to degrade, but I just wanted to give it another chance. We're down to 38k rps now in process and 6k rps remote.