ReferenceError: util is not defined

[0] /home/neo/projects/dm-iwish/node_modules/ulog/node.js:12
[0] 			logger = function(){stream.write(util.format.apply(this, arguments) + '\n')}
[0] 			                                 ^
[0]
[0] ReferenceError: util is not defined
[0]     at Object.logger (/home/neo/projects/dm-iwish/node_modules/ulog/node.js:12:37)
[0]     at Object. (/home/neo/projects/dm-iwish/node_modules/just-wait/bin/just-wait.js:64:6)
[0]     at Module._compile (module.js:556:32)
[0]     at Object.Module._extensions..js (module.js:565:10)
[0]     at Module.load (module.js:473:32)
[0]     at tryModuleLoad (module.js:432:12)
[0]     at Function.Module._load (module.js:424:3)
[0]     at Module.require (module.js:483:17)
[0]     at require (internal/module.js:20:19)
[0]     at Object. (/home/neo/projects/dm-iwish/node_modules/just-wait/index.js:1:63)
[0] npm run watch-server-start exited with code 1

@Download Can you resolve it sooner. I use just-wait module and it uses your module. Thanks.

I will have a look! Thanks for reporting it.

@zheoreh
Can you please get the new version of node.js and replace the file
/home/neo/projects/dm-iwish/node_modules/ulog/node.js
with the new version and see if that resolves it?
If so, I will promptly create a new version of both ulog and just-wait and publish them to NPM.

@Download I am sure it will be work)
But I tested and it works.
I wait for a new version of ulog module in NPM.
Thanks.

@zheoreh ulog 1.0.2 is on NPM. I will also create a new versio of just-wait and publish that as well.
Feel free to re-open if you still have issues.

Thanks. It works fine now.


HealthCheck fails because of "Unsafe Dependancy" on libgcc_s.so.1 and libstdc++.so.6 when building ChefDK on Arch Linux

While trying to build ChefDK on an Arch Linux machine I encounter the following error during the health check stage of the build.
                      [HealthCheck] E | Failed!
                      [HealthCheck] E | The following libraries have unsafe or unmet dependencies:
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/dep_selector-1.0.3/dep_gecode.so
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/ext/dep_gecode/dep_gecode.so
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/lib/dep_gecode.so

                      [HealthCheck] E | The following binaries have unsafe or unmet dependencies:

                      [HealthCheck] E | The following libraries cannot be guaranteed to be on target systems:
    --> /usr/lib/libstdc++.so.6 (0x00007f6df4fa0000)
    --> /usr/lib/libgcc_s.so.1 (0x00007f6df46e1000)
    --> /usr/lib/libstdc++.so.6 (0x00007f5ea2b7a000)
    --> /usr/lib/libgcc_s.so.1 (0x00007f5ea22bb000)
    --> /usr/lib/libstdc++.so.6 (0x00007f897cdc2000)
    --> /usr/lib/libgcc_s.so.1 (0x00007f897c503000)

                      [HealthCheck] E | The precise failures were:
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/dep_selector-1.0.3/dep_gecode.so
    DEPENDS ON: libstdc++.so.6
      COUNT: 1
      PROVIDED BY: /usr/lib/libstdc++.so.6 (0x00007f6df4fa0000)
      FAILED BECAUSE: Unsafe dependency
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/extensions/x86_64-linux/2.1.0/dep_selector-1.0.3/dep_gecode.so
    DEPENDS ON: libgcc_s.so.1
      COUNT: 1
      PROVIDED BY: /usr/lib/libgcc_s.so.1 (0x00007f6df46e1000)
      FAILED BECAUSE: Unsafe dependency
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/ext/dep_gecode/dep_gecode.so
    DEPENDS ON: libstdc++.so.6
      COUNT: 1
      PROVIDED BY: /usr/lib/libstdc++.so.6 (0x00007f5ea2b7a000)
      FAILED BECAUSE: Unsafe dependency
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/ext/dep_gecode/dep_gecode.so
    DEPENDS ON: libgcc_s.so.1
      COUNT: 1
      PROVIDED BY: /usr/lib/libgcc_s.so.1 (0x00007f5ea22bb000)
      FAILED BECAUSE: Unsafe dependency
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/lib/dep_gecode.so
    DEPENDS ON: libstdc++.so.6
      COUNT: 1
      PROVIDED BY: /usr/lib/libstdc++.so.6 (0x00007f897cdc2000)
      FAILED BECAUSE: Unsafe dependency
    --> /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/dep_selector-1.0.3/lib/dep_gecode.so
    DEPENDS ON: libgcc_s.so.1
      COUNT: 1
      PROVIDED BY: /usr/lib/libgcc_s.so.1 (0x00007f897c503000)
      FAILED BECAUSE: Unsafe dependency

I did some googling and came to the conclusion that is was throwing this because the dep-selector-libgeocode was linking against a local version of these libraries (eg: /usr/lib/libstdc++.so.6) rather than a version living under /opt/chefdk/embedded/lib/. I just don't know where the change should be made to make sure it tries to link to an embedded library or whether this could be ignored, or what.
Ruby version
[uncurlhalo@tiger omnibus-chef]$ ruby -v
ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-linux]

Built with the latests omnibus-chef version from git.

Libraries libstdc++.so, libgcc_s, and libstdc++  aren't whitelisted in ARCH target platform. As result, dep-selector-libgeocode must be dependent on these (I suppose it is via  gcc omnibus-software)
However, I don't see any such usage in omnibus-chef.

@hugosato The whitelists are in omnibus itself.

Hi @yzl, if I understood @Uncurlhalo's log correctly, he is trying to build a project for Arch platform. After quick look at the code, it seemed to me the health check failures are by design.
I would suggest him to add these libraries as dependency. Also, fwict, he needs to create his own definition for ARCH since the libgcc won't be copied under the embedded folder for his platform.
or did I miss anything?

@hugosato That sounds about right, with the caveat that the existing ARCH whitelist predates ChefDK, so there might be cases where updating the whitelist would make more sense than managing a separate dependency.  (We don't build on ARCH, so I don't have specific knowledge to contribute on that front.)


Fix model argument issue (#1198)

A quick fix to issue #1198 that makes sure one model is used throughout inject_adapter function in BaseTuner.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

The reason I want to _mark_only_adapters_as_trainable can also work without passing the model argument is the BaseTuner is already a model. So if we want to use this function outside the class we might have to call model._mark_only_adapters_as_trainable(model.model). I think this is the main use case of this function outside the class. But calling like this seems a little bit weird to me. That's why I let this function work without passing the model argument. What do you think?
If you still prefer to make model a required argument, I will change it back.

I think this is the main use case of this function outside the class.

I'm not quite sure I understand this. Do you mean that PEFT users may want to call model._mark_only_adapters_as_trainable? If that is so, I think we should add an explicit method/function for that, as _mark_only_adapters_as_trainable is supposed to be "private" and thus not called directly in user code.

Sorry for the delay, I fixed the issue according to your suggestions.


The sum of percentages

When the sum of percentages equal 1.0f,  program will crash.（Xcode7.2.1, iOS 9.2）

Please update to the new version 1.2.2 (available via CocoaPods).
Fixed in https://github.com/natalia-osa/CircleStatus/commit/238e951ede3445fb91b95b113a51445d27cba8ba.
Hi, I've just updated the code (btw added generics & nullability and few other improvements). The crash happened because of invalid comparison percentage > 1, while in fact it could add to more than 1 (because of floating numbers). I've fixed this issue and exchanged assert here to log with a warning that total or single percentage should not exceed 1. Hope it solves the issue, otherwise reopen it please. Thanks for submitting the issue!


Misspelled error message for wrong user and password

If I enter email and password that does not match, I get the below error message:

Warning message was corrected


Create blog post on debugger dancing

In this case regarding the issue outlined here https://github.com/artsy/eigen/pull/203.

poke ^


doc: brew tap Foo/bar makes user lowercase, but not documented

brew tap Linuxbrew/science
==> Tapping linuxbrew/science
Cloning into '/home/timothee/.linuxbrew/brew/Library/Taps/linuxbrew/homebrew-science'

should document in man brew that it's using lowercase(user)

Mind making a pull-request?

I don't think it's necessary to document this.


Instructions on how to manage action groups incorrect

The instructions say "After you create an action group, it's visible in the Action groups section of the Monitor pane." but that doesn't appear to be incorrect. In order to do that I have to do the following:

Open Monitor
Select the "Alerts" tab
Click the "Manage actions" toolbar button

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e27bedb5-7ff6-f4ae-eb7e-4ee25472d25b
Version Independent ID: 804b814e-49c9-7fc8-dc86-27b431a9b7df
Content: Create and manage action groups in the Azure portal - Azure Monitor
Content Source: articles/azure-monitor/platform/action-groups.md
Service: azure-monitor
Sub-service: alerts
GitHub Login: @dkamstra
Microsoft Alias: dukek

Thanks for the feedback. We have made necessary changes to the document and the changes will reflect within 24 hours.We will close the issue for now. If there are further questions , please revert and we will be glad to assist you.


feat: add blas/base/sspr

Progresses #2039.
Description

What is the purpose of this pull request?

This RFC proposes to add a routine to the symmetric rank 1 operation A = α*x*x^T + A where α is a scalar, x is an N element vector, and A is an N by N symmetric matrix supplied in packed form as defined in BLAS Level 2 routines. Specifically adding @stdlib/blas/base/sspr is proposed.
Related Issues

Does this pull request have any related issues?

This pull request:

progresses #2039

Questions

Any questions for reviewers of this pull request?

No.
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

Thanks, @kgryte for reviewing this.


Run the macOS app tests as part of the GitHub Actions build workflow

Right now the macOS app tests aren't being run, meaning there's no way to validate that the build even launches.

Duplicate of #196.


Ported tracker bio avatar to use avatar helper and cleaned up css

@keybase/react-hackers This uses the shared avatar component for the avatar in the tracker
@gabriel i changed the css a little bit, we should discuss. In general we should design our css so that when we are resizing various elements the logical layout will still 'hold'. For example the grey/green follow/following circles on the avatar were using position absolute with a top/left. But really they're bottom /right aligned so it's better to define them that way. Then if we make the avatar larger they'll still 'work' instead of being in the middle of the avatar.  I also moved the merging of some props out of the component and into the css. I think this is a little cleaner of a pattern.

:ship: :it:


⚠ gorzdrav.org has degraded performance

In bdb6501, gorzdrav.org (https://gorzdrav.org) experienced degraded performance:

HTTP code: 200
Response time: 1549 ms

Resolved: gorzdrav.org performance has improved in bb9a278.


Using more caches in Actions

[x] apt
[ ] node
[ ] node_modules

Build log
Preview build with this PR (commit): https://output.circle-artifacts.com/output/job/b2e892bf-97a6-4615-9657-52d546f6be5f/artifacts/0/index.html

Build log
Preview build with this PR (commit): https://output.circle-artifacts.com/output/job/74b31e8c-f4b0-4d4a-a82a-4e0ce9f7bd08/artifacts/0/index.html

Build log
Preview build with this PR (commit): https://output.circle-artifacts.com/output/job/052c482a-e80e-48dc-809b-4adeeb2543b4/artifacts/0/index.html


Fix ViewModelViewHost memory leak

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix
What is the current behavior? (You can also link to an open issue here)
The ViewModelViewHost leaks memory on XAML platforms.
What is the new behavior (if this is a feature change)?
The subscription to the SizeChangedEvent will be disposed via WhenActivated and it no longer leaks memory.
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements

[x] The commit follows our guidelines: https://github.com/reactiveui/reactiveui#contribute
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:

Coverage remained the same at 66.824% when pulling 23011bbd2ac7403cfaa628ded2063e0b2c319ddf on Silv3rcircl3:fix_ViewModelViewHost_memory_leak into a353559962dc4d93844e678986c8a225f228e11c on reactiveui:develop.

NOTE: there's a chance this fixes #1314 - will need to check.

Coverage remained the same at 66.824% when pulling abd0eb0d0d12dd289a078d8eaa3333e9378c582a on Silv3rcircl3:fix_ViewModelViewHost_memory_leak into a353559962dc4d93844e678986c8a225f228e11c on reactiveui:develop.

Coverage remained the same at 66.824% when pulling 441a7b651fc484e77faff864affef42eea2c10c0 on Silv3rcircl3:fix_ViewModelViewHost_memory_leak into a353559962dc4d93844e678986c8a225f228e11c on reactiveui:develop.

When is this change planned to be integrated? I was doing memory profiling of my application and I'm having memory leaks because of this. Is there otherwise a workaround how to get this fixed?

@njannink I simply copied the source code in my project with the fix and use my local VMVH. There is another issue with this one, it's calling WhenActivated a second time when you replace the ViewMode with a new one. I still need to create another PR for this, you can fix it by simply using ContenControl instead of TransitionContentControl as base class.


Support chat

Would be nice to bounce ideas off of other users, so I feel like this repo deserves a channel on gitter.im
Either that or a channel on freenode IRC
Ideas? Recommendations? Anything against this?

I wouldn't mind sitting in a gitter. I'm already in quite a few :)

We have a Slack: https://apex-dev.azurewebsites.net/

Haha, good to know.

closing :D


Watch only function

Should move this option to the same page as creat/import wallet instead of hiding inside import page.

Done in #1272


[COMMUNITY] New Reviewer: Yixin Dong

Let's welcome Yixin Dong @Ubospica  as a new reviewer. Yixin has been contributing to CUDA tensor
core performance and TVM training.

Thanks Xiyou and Wuwei! I am very happy to be promoted to TVM reviewer. I would like to express special thanks to Tianqi, Zihao, Ruihang, Siyuan, Junru and others for their help. I hope I can continue to contribute to the TVM Community！


refactor:  fluentd-pre module and packer

The ultimate goal is to start an ASG for Fluentd without making use
of Nomad, Consul or Vault services. This is so that these services
can write to Fluentd log aggregator when they start up.
In this PR, a fluentd-pre module is created to fill in the
template for the fluentd.conf file to be configured for the Fluentd
AMI. The reason to have a separate fluentd-pre module is because we
need the output URL from an already running Elasticsearch, which is
filled into the template for fluentd-conf, and we use this when
provisioning the Fluentd AMI with Ansible.
The rest of the Fluentd setup is done after the AMI is provisioned.
Note that Elasticsearch currently does not use Route53 nor have URL
output yet - will be done in another PR.

Depends on #251

closed since changes are in #255


[BUG] Random error on Export

Describe the bug
A random error appeared during the export process.
While I do not know what the issue may be, my guess is, that the plugin doesn't handle timelines with no final keyframe very well...
To Reproduce
This is only a guess what the cause is...
Steps to reproduce the behavior:

Create an animation
Add keyframes
Make sure the timeline has no keyframe at the very end
Export model

Expected behavior
Export should work fine
Error Message
------ Error ------
[object Object]  //  "Time to fire up the ol' debugger!"
------ Stack ------
Error
    at Ld (<anonymous>:234:42495)
    at <anonymous>:234:238829
    at <anonymous>:234:238994

Build ID: local-24837f47a5998ff5f420d06410af8fbe955dc1907d761b12336c16da182721bc

Screenshots
Desktop (please complete the following information):

OS: Windows
Version 10 Pro

Additional context

Please attach the project file, thanks

I'm sorry I didn't do it right away.
ship.zip

Thanks, I'll check this as soon as I can

There is something wrong with your model and I cannot identify it.
Somehow some parts of the model have missing properties, probably caused by some other blockbench extensions.
It also contains multiple misconfigurations. Every single bone have a limit, you have a lot of boxes outside of this limit.
Refer to the red box.

Also for some reason you set max scaling instead of max model size.
This made the red boxes even smaller. If you don't need to animate scaling of your model you must always set "max model size" to allow bigger models.

Fixed it for you
ship_fixed.zip
https://user-images.githubusercontent.com/27242001/229841784-0f54c1a8-7866-47af-b92b-a30789ffae4c.mp4

A random error appeared during the export process.
While I do not know what the issue may be, my guess is, that the plugin doesn't handle timelines with no final keyframe very well...

I have no idea how to trigger this, works fine for models I made


Does it need sh?

This is mostly a "what if?" discussion, not really an issue, so feel free to close!
One thing that always bugs me about build systems is how they often bottom out at shell, which introduces implicit dependency on the environment: /bin/sh might behave differently on different machines, and it doesn't exist on windows. There's also performance angle here --- there's a whole extra process between the compiler and the build system, and, for mostly no-op builds, I imagine it might add some overhead?
That's why I was a bit surprised to learn that n2 uses sh:
https://github.com/evmar/n2/blob/599e162e7badb7244802cbd434f36038084aec21/src/process_posix.rs#L85
I would have expected something like deno_task_shell:
https://github.com/denoland/deno_task_shell
That is, implementing minimal shell in n2 itself, to make sure that behavior is hermetic, cross platform, and doesn't require an extra process (of course, the users can themselves type sh -c in the task definition if they need a shell).
I am wondering if there are some deep reasons to use the shell here which I might be missing? Is it perhaps "n2 wants to treat command as a string, without any interpretation, that works on windows and needs sh on Unix?"

First, as an underlying principle n2 needs to handle Ninja semantics, and Ninja semantics is shell, so that is sort of set in stone.
I think this question you're interested might instead be: why does Ninja rely on shell?
To start with, Ninja works with command lines as strings not arrays, so there's no way for the person generating the .ninja file construct an argv array directly as appropriate for spawning.  This is arguably a design mistake in Ninja, but it's pretty deep within Ninja's semantics; we'd need array-manipulation primitives all over to not behave this way and it'd be a pretty big change.  (It might make some things nicer though, see hacks like $in_newline in Ninja...) And it's also the case that the native format for command lines on Windows is strings, not arrays, so even if Ninja supported arrays we'd still need some alternative on Windows etc.  (More discussion of Windows command lines: https://neugierig.org/software/blog/2011/10/quoting.html )
Next, and closer to what you're asking, is why we use POSIX /bin/sh instead of our own parser like Deno's.  I think the main reason is that /bin/sh parsing is what people expect when talking about Unix command lines.  For example it's common for people to write commands like my-compiler && other-command and meaning of that && is understood by shell, as are all the rules around quoting and environment variable references and PATH expansion and so on.  Re hermeticity, /bin/sh is specified by POSIX and its behavior is nailed down well across platforms.
It's possible to reimplement the shell logic in n2, but the only reasons I can see would be:

To save a process invocation.  But in practice on Unixes spawning /bin/sh is a thing done all over and is plenty fast, and spawning processes is not really in the n2 critical path.  For a no-op build we don't spawn anything, and if we do end up spawning a process it's probably something heavy like a compiler where /bin/sh doesn't add much weight.
Cross-platform portability to Windows.  But a build system targeting Windows is almost certainly going to be invoking different programs on Windows, at least for C++, but also for path reasons, at which point you are generating different command lines anyway and cross-platform compatibility isn't too helpful.

PS: Originally Ninja spawned Windows processes via the Windows shell as well, to make somecommand && echo hello work, but my recollection is that the process overhead there does start to matter and also there's a random command-line-length limit.

Thanks, that fully answers my question and then some, learned a bunch of things!


Add post compression support

We now need to compress some of the images as the image size is growing... This PR is adding an optional post-build compression support, taken from Geert's https://github.com/ManageIQ/manageiq-appliance-build/pull/167 with a few changes:

Don't use hard links when compressing/moving image files as source and destination could be on different devices
Delete original file after compression for gzip
Don't pass file_name for scp target as file_name will be different for compressed images

Hammer backport details:
$ git log -1
commit cb4b4228fe7e434859b4e62d49de2d6452977da4
Author: Joe Rafaniello<EMAIL_ADDRESS>Date:   Thu Oct 4 11:39:25 2018 -0400

    Merge pull request #288 from simaishi/post_compression

    Add post compression support

    (cherry picked from commit f1412c2d6f115662393959dff63efcd9c944c5d7)

Gaprindashvili backport details:
$ git log -1
commit a911c27dc82961359d7da9f8ea72309b251bd3f7
Author: Joe Rafaniello<EMAIL_ADDRESS>Date:   Thu Oct 4 11:39:25 2018 -0400

    Merge pull request #288 from simaishi/post_compression

    Add post compression support

    (cherry picked from commit f1412c2d6f115662393959dff63efcd9c944c5d7)


Merge vscode-workspace-resource and vscode-extension-resource

Problem
Webview API proposal (#43713) introduces two resource schemes for loading local files:

vscode-workspace-resource: Resources from the user's workspace. This can also be overridden by localResourceRoots
vscode-extension-resource: This allows reading from extension's install directory

However this scheme prevents cross origin requests between extension resources and workspace resources. vscode-extension-resource also currently allows reading any extension's resources, which may not be safe (if, for example, some crazy extension stores user creds in the extension's install directory)
Proposal
Replace these two with a new vscode-resource scheme. This scheme would allow access to files within localResourceRoots. If not specified, localResourceRoots would include:

Currently opened workspaces folders
The extension's install directory

Extensions could override this with localResourceRoots

Moving to April as this is essentially part of #43713 which is for April


Makefile not updating Docker image names when package id or version gets updated

Placeholder: make all packages' image.tar step depend on the manifest, and reference the pkg_id and version from the manifest in the docker image name
optionally name tar file [pkg-id]-[version].tar and dynamically add to manifest docker-images line, so we don't need to regenerate the tar file every time the manifest changes

why was this transferred, isn't it package dependent?

Yes, but there is no "all services" repo

please expand into checklist.


Replace Filter in Genes with Custom Generator Function

Summary
The current implementation uses a filter to select values for genes. This approach can be inefficient and lacks flexibility. We propose replacing the filter mechanism with a custom generator function.
Problem Description
The filter method used in the genes implementation is less efficient as it requires generating a large set of values and then filtering them. Additionally, it does not provide the flexibility needed for more complex gene value generation scenarios.
Proposed Solution
Implement a custom generator function to replace the filter mechanism. This generator function will directly produce the desired gene values, improving efficiency and allowing for more flexible generation strategies.
Benefits

Increased Efficiency: Direct generation of gene values reduces computational overhead.
Enhanced Flexibility: Custom generators can accommodate a wider range of gene value generation strategies.

Additional Information
This change will require updating any existing documentation and examples that rely on the old filter method. Ensure that all usage scenarios are covered and thoroughly tested.

This is a desirable feature, but have to be analyzed in more detail


There is no Comp_v6_KLD005/opt.txt for training vq

@Murrol Thanks for your great work. I want to train a new vqvae without down sampling on HumanML3d dataset. However when I run train_vq script, it threw an error saying no such file Comp_v6_KLD005/opt.txt.
Where could I download this file? Or how can I train the vq without the evaluation stage?

Please see #6

Please see #6

Hi, @Murrol .
I downloaded the file (kit_models.zip) from Google Drive (https://drive.google.com/drive/folders/1sHajltuE2xgHh91H9pFpMAYAkHaX9o57), but I don't see the Comp_v6_KLD005 folder, just three folders: rvq, t2m, tres. Am I missing something?

Please see #6

Hi, @Murrol . I downloaded the file (kit_models.zip) from Google Drive (https://drive.google.com/drive/folders/1sHajltuE2xgHh91H9pFpMAYAkHaX9o57), but I don't see the Comp_v6_KLD005 folder, just three folders: rvq, t2m, tres. Am I missing something?

It's in kit_evaluator.zip

Please see #6

Hi, @Murrol . I downloaded the file (kit_models.zip) from Google Drive (https://drive.google.com/drive/folders/1sHajltuE2xgHh91H9pFpMAYAkHaX9o57), but I don't see the Comp_v6_KLD005 folder, just three folders: rvq, t2m, tres. Am I missing something?

It's in kit_evaluator.zip

Thx! I got it!


Move drag and drop and other OWF only stuff to "run-time extensions"

extensions that are currently identified as OWF and “drag and drop” would be moved into something called “run-time extensions” or something similar

Done


HDDS-1649. On installSnapshot notification from OM leader, download checkpoint and reload OM state

Unit tests pending.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
43
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
The patch doesn't appear to include any new or modified tests.  Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

0
mvndep
38
Maven dependency ordering for branch

+1
mvninstall
533
trunk passed

+1
compile
285
trunk passed

+1
checkstyle
80
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
1019
branch has no errors when building and testing our client artifacts.

+1
javadoc
206
trunk passed

0
spotbugs
355
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
595
trunk passed

_ Patch Compile Tests _

0
mvndep
31
Maven dependency ordering for patch

-1
mvninstall
135
hadoop-ozone in the patch failed.

-1
compile
53
hadoop-ozone in the patch failed.

-1
javac
53
hadoop-ozone in the patch failed.

-0
checkstyle
38
hadoop-ozone: The patch generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
745
patch has no errors when building and testing our client artifacts.

+1
javadoc
161
the patch passed

-1
findbugs
109
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
170
hadoop-hdds in the patch failed.

-1
unit
107
hadoop-ozone in the patch failed.

+1
asflicense
37
The patch does not generate ASF License warnings.

5014

Reason
Tests

Failed junit tests
hadoop.ozone.container.common.impl.TestHddsDispatcher

hadoop.ozone.container.ozoneimpl.TestOzoneContainer

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 9e99e3e21d68 4.4.0-141-generic #167~14.04.1-Ubuntu SMP Mon Dec 10 13:20:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 5740eea

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-compile-hadoop-ozone.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/diff-checkstyle-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/testReport/

Max. process+thread count
361 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
37
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
21
Maven dependency ordering for branch

+1
mvninstall
467
trunk passed

+1
compile
259
trunk passed

+1
checkstyle
73
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
866
branch has no errors when building and testing our client artifacts.

+1
javadoc
162
trunk passed

0
spotbugs
316
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
505
trunk passed

-0
patch
365
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
35
Maven dependency ordering for patch

-1
mvninstall
138
hadoop-ozone in the patch failed.

-1
compile
56
hadoop-ozone in the patch failed.

-1
javac
56
hadoop-ozone in the patch failed.

-0
checkstyle
41
hadoop-ozone: The patch generated 5 new + 0 unchanged - 0 fixed = 5 total (was 0)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
680
patch has no errors when building and testing our client artifacts.

+1
javadoc
162
the patch passed

-1
findbugs
104
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
279
hadoop-hdds in the patch failed.

-1
unit
55
hadoop-ozone in the patch failed.

+1
asflicense
43
The patch does not generate ASF License warnings.

4599

Reason
Tests

Failed junit tests
hadoop.hdds.scm.container.placement.algorithms.TestContainerPlacementFactory

hadoop.ozone.om.exceptions.TestResultCodes

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux cee87f92baa9 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 5e6cc6f

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-compile-hadoop-ozone.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/diff-checkstyle-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/testReport/

Max. process+thread count
535 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Reviewing this patch, @hanishakoneru can you resolve the merge conflict meanwhile?

Question:
In ShouldInstallSnapshot, it calls getLatestSnapshot() from stateMachineStorage, as we have our own snapshot implementation in stateMachine, do we need to override that method to provide correct snapshotInfo? Or could you provide some info how this works?

I am mostly +1 on this change. Couple of minor comments and one thing I requested Bharat to double check.

Question:
In ShouldInstallSnapshot, it calls getLatestSnapshot() from stateMachineStorage, as we have our own snapshot implementation in stateMachine, do we need to override that method to provide correct snapshotInfo? Or could you provide some info how this works?

We do not want the snapshots to be handled via Ratis. When a follower receives installSnaphsot notification, it sends the new loaded DB's snapshot index back to the leader. The leader updates the followers snaphsot index through this.
But when Ratis server is starting up, it should be able to determine the latest snapshot index. Otherwise, all the logs will be replayed from the start. I will create a new Jira to address this. Thanks Bharat.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
70
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
22
Maven dependency ordering for branch

+1
mvninstall
487
trunk passed

+1
compile
305
trunk passed

+1
checkstyle
74
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
965
branch has no errors when building and testing our client artifacts.

+1
javadoc
164
trunk passed

0
spotbugs
349
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
553
trunk passed

_ Patch Compile Tests _

0
mvndep
32
Maven dependency ordering for patch

-1
mvninstall
160
hadoop-ozone in the patch failed.

-1
compile
62
hadoop-ozone in the patch failed.

-1
cc
62
hadoop-ozone in the patch failed.

-1
javac
62
hadoop-ozone in the patch failed.

+1
checkstyle
84
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
756
patch has no errors when building and testing our client artifacts.

+1
javadoc
180
the patch passed

-1
findbugs
108
hadoop-ozone in the patch failed.

_ Other Tests _

+1
unit
339
hadoop-hdds in the patch passed.

-1
unit
118
hadoop-ozone in the patch failed.

+1
asflicense
38
The patch does not generate ASF License warnings.

5149

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux 5fd557cb2f6c 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d5ef38b

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-compile-hadoop-ozone.txt

cc
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-compile-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/testReport/

Max. process+thread count
411 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
98
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
24
Maven dependency ordering for branch

+1
mvninstall
527
trunk passed

+1
compile
269
trunk passed

+1
checkstyle
76
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
959
branch has no errors when building and testing our client artifacts.

+1
javadoc
182
trunk passed

0
spotbugs
375
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
606
trunk passed

_ Patch Compile Tests _

0
mvndep
33
Maven dependency ordering for patch

+1
mvninstall
442
the patch passed

+1
compile
279
the patch passed

+1
cc
279
the patch passed

+1
javac
279
the patch passed

+1
checkstyle
85
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
764
patch has no errors when building and testing our client artifacts.

+1
javadoc
169
the patch passed

+1
findbugs
537
the patch passed

_ Other Tests _

+1
unit
336
hadoop-hdds in the patch passed.

-1
unit
2175
hadoop-ozone in the patch failed.

+1
asflicense
55
The patch does not generate ASF License warnings.

7789

Reason
Tests

Failed junit tests
hadoop.ozone.client.rpc.TestMultiBlockWritesWithDnFailures

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.om.snapshot.TestOzoneManagerSnapshotProvider

hadoop.ozone.client.rpc.TestFailureHandlingByClient

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient

hadoop.ozone.TestSecureOzoneCluster

hadoop.ozone.container.server.TestSecureContainerServer

hadoop.ozone.client.rpc.Test2WayCommitInRatis

hadoop.ozone.container.ozoneimpl.TestSecureOzoneContainer

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.hdds.scm.pipeline.TestRatisPipelineCreateAndDestory

Subsystem
Report/Notes

Docker
Client=18.09.7 Server=18.09.7 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux f2938c9c233e 4.15.0-52-generic #56-Ubuntu SMP Tue Jun 4 22:49:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d545f9c

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/4/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/4/testReport/

Max. process+thread count
4968 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/4/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
66
Maven dependency ordering for branch

+1
mvninstall
482
trunk passed

+1
compile
265
trunk passed

+1
checkstyle
77
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
865
branch has no errors when building and testing our client artifacts.

+1
javadoc
187
trunk passed

0
spotbugs
316
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
509
trunk passed

_ Patch Compile Tests _

0
mvndep
74
Maven dependency ordering for patch

+1
mvninstall
435
the patch passed

+1
compile
271
the patch passed

+1
cc
271
the patch passed

+1
javac
271
the patch passed

+1
checkstyle
73
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
648
patch has no errors when building and testing our client artifacts.

+1
javadoc
159
the patch passed

+1
findbugs
536
the patch passed

_ Other Tests _

+1
unit
277
hadoop-hdds in the patch passed.

-1
unit
1639
hadoop-ozone in the patch failed.

+1
asflicense
50
The patch does not generate ASF License warnings.

6814

Reason
Tests

Failed junit tests
hadoop.ozone.TestSecureOzoneCluster

hadoop.ozone.om.snapshot.TestOzoneManagerSnapshotProvider

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient

hadoop.ozone.container.ozoneimpl.TestSecureOzoneContainer

hadoop.ozone.client.rpc.TestFailureHandlingByClient

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.client.rpc.TestMultiBlockWritesWithDnFailures

hadoop.ozone.container.server.TestSecureContainerServer

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux 0196a0d19d2c 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d545f9c

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/5/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/5/testReport/

Max. process+thread count
5388 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/5/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

/retest

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
83
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
23
Maven dependency ordering for branch

+1
mvninstall
524
trunk passed

+1
compile
254
trunk passed

+1
checkstyle
66
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
837
branch has no errors when building and testing our client artifacts.

+1
javadoc
149
trunk passed

0
spotbugs
326
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
522
trunk passed

_ Patch Compile Tests _

0
mvndep
31
Maven dependency ordering for patch

+1
mvninstall
438
the patch passed

+1
compile
274
the patch passed

+1
cc
274
the patch passed

+1
javac
274
the patch passed

+1
checkstyle
76
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
638
patch has no errors when building and testing our client artifacts.

+1
javadoc
154
the patch passed

+1
findbugs
571
the patch passed

_ Other Tests _

-1
unit
239
hadoop-hdds in the patch failed.

-1
unit
2317
hadoop-ozone in the patch failed.

+1
asflicense
46
The patch does not generate ASF License warnings.

7392

Reason
Tests

Failed junit tests
hadoop.ozone.container.ozoneimpl.TestOzoneContainer

hadoop.ozone.container.server.TestSecureContainerServer

hadoop.ozone.om.snapshot.TestOzoneManagerSnapshotProvider

hadoop.ozone.TestSecureOzoneCluster

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.container.ozoneimpl.TestSecureOzoneContainer

hadoop.ozone.client.rpc.TestMultiBlockWritesWithDnFailures

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

hadoop.hdds.scm.pipeline.TestRatisPipelineCreateAndDestory

hadoop.ozone.client.rpc.TestFailureHandlingByClient

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.hdds.scm.pipeline.TestPipelineClose

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux 2bc98f91d488 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 6282c02

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/6/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/6/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/6/testReport/

Max. process+thread count
4916 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/6/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

/retest

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
36
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
23
Maven dependency ordering for branch

+1
mvninstall
484
trunk passed

+1
compile
251
trunk passed

+1
checkstyle
66
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
799
branch has no errors when building and testing our client artifacts.

+1
javadoc
149
trunk passed

0
spotbugs
316
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
503
trunk passed

_ Patch Compile Tests _

0
mvndep
30
Maven dependency ordering for patch

+1
mvninstall
458
the patch passed

+1
compile
271
the patch passed

+1
cc
271
the patch passed

+1
javac
271
the patch passed

+1
checkstyle
80
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
645
patch has no errors when building and testing our client artifacts.

+1
javadoc
157
the patch passed

+1
findbugs
566
the patch passed

_ Other Tests _

+1
unit
301
hadoop-hdds in the patch passed.

-1
unit
269
hadoop-ozone in the patch failed.

+1
asflicense
50
The patch does not generate ASF License warnings.

5301

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux f434386d5f73 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 7f1b76c

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/7/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/7/testReport/

Max. process+thread count
1209 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/7/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Rebased with latest trunk.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
38
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 4 new or modified test files.

_ trunk Compile Tests _

0
mvndep
71
Maven dependency ordering for branch

+1
mvninstall
489
trunk passed

+1
compile
259
trunk passed

+1
checkstyle
76
trunk passed

+1
mvnsite
1
trunk passed

+1
shadedclient
882
branch has no errors when building and testing our client artifacts.

+1
javadoc
163
trunk passed

0
spotbugs
316
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
512
trunk passed

_ Patch Compile Tests _

0
mvndep
37
Maven dependency ordering for patch

+1
mvninstall
459
the patch passed

+1
compile
256
the patch passed

+1
cc
256
the patch passed

+1
javac
256
the patch passed

+1
checkstyle
70
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
1
The patch has no ill-formed XML file.

+1
shadedclient
621
patch has no errors when building and testing our client artifacts.

+1
javadoc
163
the patch passed

+1
findbugs
529
the patch passed

_ Other Tests _

+1
unit
280
hadoop-hdds in the patch passed.

-1
unit
1979
hadoop-ozone in the patch failed.

+1
asflicense
50
The patch does not generate ASF License warnings.

7116

Reason
Tests

Failed junit tests
hadoop.ozone.client.rpc.TestBlockOutputStreamWithFailures

hadoop.ozone.om.snapshot.TestOzoneManagerSnapshotProvider

hadoop.ozone.client.rpc.TestCloseContainerHandlingByClient

hadoop.ozone.client.rpc.TestOzoneClientRetriesOnException

hadoop.ozone.client.rpc.TestOzoneRpcClient

hadoop.ozone.client.rpc.TestMultiBlockWritesWithDnFailures

hadoop.ozone.container.ozoneimpl.TestSecureOzoneContainer

hadoop.ozone.TestStorageContainerManager

hadoop.ozone.client.rpc.TestOzoneRpcClientWithRatis

hadoop.ozone.client.rpc.TestSecureOzoneRpcClient

hadoop.ozone.client.rpc.TestFailureHandlingByClient

hadoop.ozone.client.rpc.TestOzoneAtRestEncryption

Subsystem
Report/Notes

Docker
Client=18.09.8 Server=18.09.8 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-948/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/948

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml cc

uname
Linux 997c627396b6 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / acdb0a1

Default Java
1.8.0_212

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/8/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/8/testReport/

Max. process+thread count
5092 (vs. ulimit of 5500)

modules
C: hadoop-hdds/common hadoop-ozone/common hadoop-ozone/integration-test hadoop-ozone/ozone-manager U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-948/8/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

/retest

I am merging this with couple of caveats.

There are numerous integration test failures. However these tests also fail in current trunk, so they are likely unrelated.
More seriously the integration test TestOzoneManagerSnapshotProvider.testDownloadCheckpoint which exercises related functionality failed in the pre-commit run. It passes for me locally with the patch applied. So this is likely a flaky test.


🐛 BUG: MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start.

Which Cloudflare product(s) does this pertain to?
Pages, Workers Runtime, Wrangler core, Miniflare
What version(s) of the tool(s) are you using?
wrangler 3.22.3, miniflare version 3.20231218.1, workerd 1.20231218.0
What version of Node are you using?
v16.17.1
What operating system are you using?
Debian 12.4 (latest stable)
Describe the Bug
Hey I'm a junior developer (or maybe lower) and I followed
https://developers.cloudflare.com/pages/framework-guides/deploy-a-react-site/
to deploy a static React site to cloudflare pages. It worked brilliantly, and I was starting on the development (which, as a newbie, means enthusiastically testing out code that doesn't work).
Suddenly I started getting these errors when through up a development site.
I tried removing bits of code that might have caused it that I'd recently changed, and I don't think that's it.
At first glance, the error log reads like "oh, you already have something running on that port"
but if you look at the examples in error between those - you see what's happening:

The dev site starts
Wrangler tries to do some magic to bring the workers in.
This fails, but the dev site continues
when the dev site is terminated - we see this repeat
and whilst the dev site is still running, we see it fail before this point.

I did a bit of digging into the locations of the error messages.
/home/tdobson/Videos/dev/save-old-glossop/node_modules/wrangler/wrangler-dist/cli.js:29374
            throw a;
            ^

When I look at that file, it literally just says
          process.argv.slice(2);
          process.on("uncaughtException", function(a) {
            throw a;
          });
          process.on(
            "unhandledRejection",
            function(a) {
              throw a;
            }
          );

In miniflare/dist/src/index.js, I tried adding a couple of console logs - and to me, that didn't add much useful, but maybe it did to you.

    if (this.#disposeController.signal.aborted)
      return;
    console.error(maybeSocketPorts)
    console.error(configBuffer)
    console.error(runtimeOpts)

    if (maybeSocketPorts === void 0) {
      throw new MiniflareCoreError(
        "ERR_RUNTIME_FAILURE",
        "The Workers runtime failed to start. There is likely additional logging output above."
      );
    }

The project compiles and deploys to Cloudflare Pages just nicely.
From my point of view, it's frustrating because I don't care about serverside functions.  If there's an obvious option I can use to disable it, I'd be hyped - this is my first project with Cloudflare Pages and I was enjoying it til this point.
I wonder if this is linked to this other bug report. I suspect not, but if it is - feel free to merge etc
Thanks for taking a look at this. Happy to provide other info etc.
If you want me to test something for you - I'd be happy to, and if you could dumb things down/give me the commands to run - I'd really appreciate it.
Please provide a link to a minimal reproduction
https://github.com/tdobson/cloudflare-wrangler-setup-problem-example
Please provide any relevant error logs

tdobson@tragicomix:~/Videos/dev/save-old-glossop$  wrangler pages dev --compatibility-date=2023-12-18 --port 3000 --log-level=debug -- npm start
Running npm start...
Sleeping 5 seconds to allow proxy process to start before attempting to automatically determine port...
To skip, specify the proxy port with --proxy.
[proxy]:
><EMAIL_ADDRESS>start
> react-scripts start

✘ [ERROR] [proxy]: (node:56144) [DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE] DeprecationWarning: 'onAfterSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.

  (Use `node --trace-deprecation ...` to show where the warning was created)

✘ [ERROR] [proxy]: (node:56144) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.

[proxy]: Starting the development server...

[proxy]: Compiled successfully!

[proxy]:
You can now view save-old-glossop in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://<IP_ADDRESS>:3000

Note that the development build is not optimized.

[proxy]: To create a production build, use npm run build.

[proxy]: webpack compiled successfully

Automatically determined the proxy port to be 3000.
No functions. Shimming...
 ⛅ wrangler 3.22.3
-------------------
▲ [WARNING] --local is no longer required and will be removed in a future version.

  `wrangler dev` now uses the local Cloudflare Workers runtime by default. 🎉

Retrieving cached values for userId from node_modules/.cache/wrangler
Metrics dispatcher: Dispatching disabled - would have sent {"type":"event","name":"run dev","properties":{"local":true,"usesTypeScript":true}}.
Using vars defined in .dev.vars
⎔ Starting local server...
Not Implemented Error: BundlerController#onConfigUpdate
ProxyWorker miniflare options changed, reinstantiating...
Error in ProxyController: Could not connect to InspectorProxyWorker
 MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at Miniflare.#assembleAndUpdateConfig (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:8902:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Mutex.runWith (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:3863:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}
=> Error contextual data: {
  config: {
    name: 'worker',
    script: { contents: '' },
    dev: {
      server: [Object],
      inspector: [Object],
      urlOverrides: [Object],
      liveReload: false
    }
  },
  bundle: undefined
}
Error in ProxyController: Failed to send message to InspectorProxyWorker: {"type":"reloadStart"}
 MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at Miniflare.#assembleAndUpdateConfig (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:8902:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Mutex.runWith (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:3863:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}
=> Error contextual data: {
  config: {
    name: 'worker',
    script: { contents: '' },
    dev: {
      server: [Object],
      inspector: [Object],
      urlOverrides: [Object],
      liveReload: false
    }
  },
  bundle: undefined
}
╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ [b] open a browser, [d] open Devtools, [c] clear console, [x] to exit                                                                                │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
/usr/local/lib/node_modules/wrangler/wrangler-dist/cli.js:29374
            throw a;
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at Miniflare.#assembleAndUpdateConfig (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:8902:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Mutex.runWith (/usr/local/lib/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:3863:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Just tried updating my node environment to Node.js v18.19.0. The issue persists.

tdobson@tragicomix:~/Videos/dev/save-old-glossop-not-working$ npm run
Lifecycle scripts included in<EMAIL_ADDRESS>  start
    react-scripts start
  test
    react-scripts test

available via `npm run-script`:
  build
    react-scripts build
  eject
    react-scripts eject
  pages:dev
    wrangler pages dev --compatibility-date=2023-12-18 --port 3000 -- npm start
  pages:deploy
    npm run build && wrangler pages deploy ./build

tdobson@tragicomix:~/Videos/dev/save-old-glossop-not-working$ npm run pages:dev

><EMAIL_ADDRESS>pages:dev
> wrangler pages dev --compatibility-date=2023-12-18 --port 3000 -- npm start

Running npm start...
Sleeping 5 seconds to allow proxy process to start before attempting to automatically determine port...
To skip, specify the proxy port with --proxy.
[proxy]:
><EMAIL_ADDRESS>start
> react-scripts start

✘ [ERROR] [proxy]: (node:99096) [DEP_WEBPACK_DEV_SERVER_ON_AFTER_SETUP_MIDDLEWARE] DeprecationWarning: 'onAfterSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.

  (Use `node --trace-deprecation ...` to show where the warning was created)

✘ [ERROR] [proxy]: (node:99096) [DEP_WEBPACK_DEV_SERVER_ON_BEFORE_SETUP_MIDDLEWARE] DeprecationWarning: 'onBeforeSetupMiddleware' option is deprecated. Please use the 'setupMiddlewares' option.

[proxy]: Starting the development server...

[proxy]: Compiled successfully!

[proxy]:
You can now view save-old-glossop in the browser.

  Local:            http://localhost:3000
  On Your Network:  http://<IP_ADDRESS>:3000

[proxy]:
Note that the development build is not optimized.
To create a production build, use npm run build.

Automatically determined the proxy port to be 3000.
No functions. Shimming...
[proxy]: webpack compiled successfully

 ⛅ wrangler 3.22.3
-------------------
▲ [WARNING] --local is no longer required and will be removed in a future version.

  `wrangler dev` now uses the local Cloudflare Workers runtime by default. 🎉

Using vars defined in .dev.vars
⎔ Starting local server...
undefined
<Buffer 00 00 00 00 ae 5c 00 00 00 00 00 00 00 00 04 00 0d 00 00 00 df 00 00 00 a5 81 00 00 67 00 00 00 00 00 00 00 00 00 00 00 3d 82 00 00 0f 00 00 00 24 00 ... 189766 more bytes>
{
  signal: AbortSignal { aborted: false },
  entryAddress: 'localhost:3000',
  loopbackPort: 40761,
  requiredSockets: [ 'entry', 'direct:1' ],
  inspectorAddress: undefined,
  verbose: false,
  handleRuntimeStdio: [Function (anonymous)]
}
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ [b] open a browser, [d] open Devtools, [c] clear console, [x] to exit                                                                                │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
/home/tdobson/Videos/dev/save-old-glossop-not-working/node_modules/wrangler/wrangler-dist/cli.js:29374
            throw a;
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (/home/tdobson/Videos/dev/save-old-glossop-not-working/node_modules/miniflare/dist/src/index.js:8906:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Mutex.runWith (/home/tdobson/Videos/dev/save-old-glossop-not-working/node_modules/miniflare/dist/src/index.js:3863:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Node.js v18.19.0

same for node 20, bare "hello-world" worker created by C3 cli.

if you are using a mac, it likely has to do with folder permissions, make sure you give yourself full rights: chown R user folder etc.
That worked for me.

Works for me if i first kill any proccess on port 3000
fuser -k 3000/tcp
and then run
npx wrangler pages dev --compatibility-date=2023-12-18 -- npm start
Note that i have removed --port 3000
Using WSL
node: v16.20.2
wrangler: 3.25.0

@tdobson can you please re-run this command with WRANGLER_LOG=debug, or if you're running this on the latest version of wrangler, these logs should already be written to a file logged at the end of your session.
can you please then provide these debug logs so we can investigate? thanks!

Not @tdobson but I was running into the same thing w/ node 20.10.0 and Wrangler 3.26.0, here are my debug logs:

logs

--- 2024-02-05T20:23:11.291Z debug
🪵  Writing logs to "/Users/roryabraham/Library/Preferences/.wrangler/logs/wrangler-2024-02-05_20-23-11_224.log"
---

--- 2024-02-05T20:23:11.291Z debug
Failed to load .env file ".env": Error: ENOENT: no such file or directory, open '.env'
    at Object.openSync (node:fs:581:18)
    at Object.readFileSync (node:fs:457:35)
    at tryLoadDotEnv (/Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:124257:72)
    at loadDotEnv (/Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:124266:12)
    at /Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:162342:20
    at /Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:131131:16
    at maybeAsyncResult (/Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:129352:44)
    at /Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:131130:14
    at /Users/roryabraham/Expensidev/Cloudflare-Workers/node_modules/wrangler/wrangler-dist/cli.js:129339:22
    at Array.reduce (<anonymous>) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: '.env'
}
---

--- 2024-02-05T20:23:11.297Z log
 ⛅ wrangler 3.26.0
-------------------
---

--- 2024-02-05T20:23:11.315Z debug
Metrics dispatcher: Posting data {"type":"event","name":"run dev","properties":{"local":true,"usesTypeScript":false}}
---

--- 2024-02-05T20:23:11.319Z log
Using vars defined in .dev.vars
---

--- 2024-02-05T20:23:11.319Z log
Your worker has access to the following bindings:
- Vars:
  - CSP_DEFAULT_SRC: "(hidden)"
  - CSP_SCRIPT_SRC: "(hidden)"
  - CSP_CONNECT_SRC: "(hidden)"
  - blob: "(hidden)"
  - CSP_IMG_SRC: "(hidden)"
  - data: "(hidden)"
  - CSP_STYLE_SRC: "(hidden)"
  - CSP_FONT_SRC: "(hidden)"
  - CSP_FRAME_SRC: "(hidden)"
  - CSP_WORKER_SRC: "(hidden)"
  - CSP_CHILD_SRC: "(hidden)"
  - CSP_MEDIA_SRC: "(hidden)"
  - CSP_FRAME_ANCESTORS: "(hidden)"
---

--- 2024-02-05T20:23:11.363Z log
⎔ Starting local server...
---

--- 2024-02-05T20:23:11.398Z debug
workerd/util/symbolizer.c++:96: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
*** Fatal uncaught kj::Exception: kj/compat/tls.c++:72: failed: OpenSSL error; message = error:0900006e:PEM routines:OPENSSL_internal:NO_START_LINE
stack: 102e1b53b 102e1d2c3 1020e45a3 1020e66c3 1020eddeb 1020f15b3 1020eff03 1020dd147 1020e176b 1020e1653 1020e163b 1041ab883 1041abbcb 1041aa32b 1041aa0fb 1020d41af 18d6690df
---

Interesting – seems to be an SSL error?

same here with miniflare README example code
maybe related to https://github.com/cloudflare/workers-sdk/issues/4284?
import { Miniflare } from "miniflare";

// Create a new Miniflare instance, starting a workerd server
const mf = new Miniflare({
	script: `addEventListener("fetch", (event) => {
    event.respondWith(new Response("Hello Miniflare!"));
  })`,
});

// Send a request to the workerd server, the host is ignored
const response = await mf.dispatchFetch("http://localhost:8787/");
console.log(await response.text()); // Hello Miniflare!

// Cleanup Miniflare, shutting down the workerd server
await mf.dispose();

zsh ❯ cat package.json
{
  "name": "little-tooth-5b50",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "deploy": "wrangler deploy",
    "dev": "wrangler dev",
    "start": "wrangler dev"
  },
  "devDependencies": {
    "wrangler": "^3.0.0"
  }
}%

zsh ❯ cat test.mjs
import { Miniflare } from 'miniflare';

// Create a new Miniflare instance, starting a workerd server
const mf = new Miniflare({
        script: `addEventListener("fetch", (event) => {
    event.respondWith(new Response("Hello Miniflare!"));
  })`,
});

// Send a request to the workerd server, the host is ignored
const response = await mf.dispatchFetch('http://localhost:8787/');
console.log(await response.text()); // Hello Miniflare!

// Cleanup Miniflare, shutting down the workerd server
await mf.dispose();

zsh ❯ node --version
v21.5.0

zsh ❯ node test.mjs
workerd/util/symbolizer.c++:96: warning: Not symbolizing stack traces because $LLVM_SYMBOLIZER is not set. To symbolize stack traces, set $LLVM_SYMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
*** Fatal uncaught kj::Exception: kj/compat/tls.c++:72: failed: OpenSSL error; message = error:0900006e:PEM routines:OPENSSL_internal:NO_START_LINE
stack: 104e9353b 104e952c3 10415c5a3 10415e6c3 104165deb 1041695b3 104167f03 104155147 10415976b 104159653 10415963b 106223883 106223bcb 10622232b 1062220fb 10414c1af 182fd50df
/Users/yqrashawn/workspace/home/little-tooth-5b50/node_modules/miniflare/dist/src/index.js:8480
      throw new MiniflareCoreError(
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (/Users/yqrashawn/workspace/home/little-tooth-5b50/node_modules/miniflare/dist/src/index.js:8480:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Mutex.runWith (/Users/yqrashawn/workspace/home/little-tooth-5b50/node_modules/miniflare/dist/src/index.js:3405:16)
    at async #waitForReady (/Users/yqrashawn/workspace/home/little-tooth-5b50/node_modules/miniflare/dist/src/index.js:8530:5)
    at async Miniflare.dispatchFetch (/Users/yqrashawn/workspace/home/little-tooth-5b50/node_modules/miniflare/dist/src/index.js:8599:5)
    at async file:///Users/yqrashawn/workspace/home/little-tooth-5b50/test.mjs:11:18 {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Node.js v21.5.0

@penalosa same shit...
YMBOLIZER to the location of the llvm-symbolizer binary. When running tests under bazel, use `--test_env=LLVM_SYMBOLIZER=<path>`.
*** Fatal uncaught kj::Exception: kj/compat/tls.c++:72: failed: OpenSSL error; message = error:0900006e:PEM routines:OPENSSL_internal:NO_START_LI
NE

https://github.com/cloudflare/workers-sdk/issues/4420#issuecomment-1825944390

@a5r0n does the comment in #4420 solve your problem (i.e. do you have a malformed certificate file)? If so, we should definitely add some better messaging around this error case, since it seems to be relatively common.

@a5r0n Could you try running NODE_EXTRA_CA_CERTS="" wrangler pages dev --compatibility-date=2023-12-18 -- npm start and see what the output of that is?

I resolved the issue by disabling my IPv6 localhost in my /etc/hosts files. Like,
<IP_ADDRESS>       localhost
#fe80::1         localhost

OK it looks like there is no more action for us to do here.
In most cases this is due to an invalid cert file, which can be checked by following the instructions here: https://github.com/cloudflare/workers-sdk/issues/4709#issuecomment-1964230217. If that is OK then there is a problem with the cert file.
In the case of @xeodou it seems like the problem was not related to the cert file per se.

I'm trying to trace a similar problem however I'm not using pages, just doing basic wrangler worker development.
A recent wrangler update seems to have triggered the problem, everything ran fine before then,
I first hit issues when I did a wrangler init to create a new project, and got errors running wrangler dev, so I updated wrangler, then npm, and now nothing works.
I've tried the solutions above regarding certs however I'm not using pages and everything ran fine previously.  Here's what I get;
NODE_EXTRA_CA_CERTS="" wrangler dev --compatibility-date=2023-12-18 -- npm start

'NODE_EXTRA_CA_CERTS' is not recognized as an internal or external command,
operable program or batch file.
I'll note that one of the things logging identified is that when wrangler init did not create the .dev or .dev.vars files, which it seems to require now?  However creating those files didn't resolve all of the issues. Log file attached.
wrangler-2024-07-06_09-32-36_362.log

-------------------------------------------------------

Using vars defined in .dev.vars
⎔ Starting local server...
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮│ [b] open a browser, [d] open Devtools, [l] turn off local mode, [c] clear console, [x] to exit                                                                                │╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯C:\Users\ fanbo3\myTestMini\miniapp\dddname\node_modules\wrangler\wrangler-dist\cli.js:29765
            throw a;
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (C:\Users\ \ fanbo3\myTestMini\miniapp\dddname\node_modules\miniflare\dist\src\index.js:9178:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Mutex.runWith (C:\Users\ \fanbo3\myTestMini\miniapp\dddname\node_modules\miniflare\dist\src\index.js:3521:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Node.js v20.15.0`

This question keeps popping up, how should I handle it?

I had the same problem. I switched wrangler to wrangler 3.57.1 and it worked fine.

        throw a;
        ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
at #assembleAndUpdateConfig (C:\Users\Asmin\Desktop\serverless\my-app\node_modules\miniflare\dist\src\index.js:9178:13)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Mutex.runWith (C:\Users\Asmin\Desktop\serverless\my-app\node_modules\miniflare\dist\src\index.js:3521:16) {
code: 'ERR_RUNTIME_FAILURE',
cause: undefined
}
Node.js v20.11.0
i changed the version to 3.57.1 but still not working

I believe you are experiencing an issue with a recent change to workerd that break on Windows 11?
See https://github.com/cloudflare/workers-sdk/issues/6170

I believe you are experiencing an issue with a recent change to workerd that break on Windows 11? See #6170

i have windows 10 can you provide me anything to fix this issue its been an houe now and i am not able to find something

 ERROR  *** Received structured exception #0xc0000005: access violation; stack: 7ff9ed0e301f 7ff788f594eb 7ff788f595b3 7ff788f4d1ec 7ff788f4d197 7ff7887c832e 7ff7887c863f 7ff7876b1706 7ff7876b14ea 7ff78894047f 7ff788947636 7ff78894099c 7ff788947636 7ff78893e30c 7ff7876a1551 7ff789fdc8df 7ffa0e27257c 7ffa0eb4af27

 ERROR  Failed to initialize wrangler bindings proxy The Workers runtime failed to start. There is likely additional logging output above.

  at Miniflare2.#assembleAndUpdateConfig (node_modules\miniflare\src\index.ts:1343:10)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  at Mutex.runWith (node_modules\miniflare\src\workers\shared\sync.ts:66:45)
  at Miniflare2.#waitForReady (node_modules\miniflare\src\index.ts:1425:3)
  at Miniflare2._getProxyClient (node_modules\miniflare\src\index.ts:1631:3)
  at Miniflare2.getBindings (node_modules\miniflare\src\index.ts:1654:23)
  at async getPlatformProxy (node_modules\wrangler\wrangler-dist\cli.js:210786:20)
  at _getPlatformProxy (node_modules\nitro-cloudflare-dev\dist\runtime\plugin.dev.mjs:41:17)

We have fixed this regression for nitro proxy using this method.

I resolved the issue by disabling my IPv6 localhost in my /etc/hosts files. Like,
<IP_ADDRESS>       localhost
#fe80::1         localhost

How to do this on windows?

I fixed this error by running
npm install<EMAIL_ADDRESS>I changed it from 3.68.0 to 3.57.1

@divofred
I did the same, but now it gives a warning :

@divofred
I did the same, but now it gives a warning :

You just have to change the compatibility date to "2024-05-12"
@AnantKrSharma

umm.. is that a good practice ?

umm.. is that a good practice ?

The latest version of wrangler is buggy, so you are downgrading to the previous version. Since you are going back to 3.57.1, it is good practice to change the compatibility date. Hope this makes it clear

oh.. so the problem is in Wrangler..
Thanks for your help!

我通过运行修复了这个错误， npm install<EMAIL_ADDRESS>我将其从 3.68.0 更改为 3.57.1

用这个可以了.

I was also getting this error on Windows 10, with the latest wranger installed a few minutes ago via npm install wrangler --save-dev. I think it was version 3.69.1 on Node v21.7.3.
The error is quite vague and unhelpful, but a Google search led me here.
I ran:
npm install<EMAIL_ADDRESS>npm run dev

...and now the dev server is starting up correctly.

I got the following error while using the latest version of Wrangler:
"MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.".
Upon looking into files, I found that the error is coming from the following code:
"if (maybeSocketPorts === void 0) {
throw new MiniflareCoreError(
"ERR_RUNTIME_FAILURE",
"The Workers runtime failed to start. There is likely additional logging output above."
);
}"
Initially, the latest version worked for me but failed when I attempted to create a second application. Fortunately, downgrading Wrangler to version 3.57.1 resolved the issue for me.

Same error in Windows 10, even following steps from https://github.com/cloudflare/workers-sdk/issues/4709#issuecomment-1964230217 do not work in a hello world project:
PS C:\Users\Carlo\--project--> set NODE_EXTRA_CA_CERTS ""
PS C:\Users\Carlo\--project--> npx wrangler dev

 ⛅ wrangler 3.71.0
-------------------

⎔ Starting local server...

C:\Users\Carlo\--project--\node_modules\wrangler\wrangler-dist\cli.js:29768
            throw a;
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (C:\Users\Carlo\--project--\node_modules\miniflare\dist\src\index.js:9178:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Mutex.runWith (C:\Users\Carlo\--project--\node_modules\miniflare\dist\src\index.js:3521:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Node.js v22.6.0

The latest version without the error is 3.61.0, other versions like 3.62.0 give the error.

I am having the same issue on Fedora Linux 40.
I tried downgrading the Wrangler version from latest to 3.57.1 but it still doesn’t work, can anyone help?

Same error in Windows 10, even following steps from #4709 (comment) do not work in a hello world project:
PS C:\Users\Carlo\--project--> set NODE_EXTRA_CA_CERTS ""
PS C:\Users\Carlo\--project--> npx wrangler dev

 ⛅ wrangler 3.71.0
-------------------

⎔ Starting local server...

C:\Users\Carlo\--project--\node_modules\wrangler\wrangler-dist\cli.js:29768
            throw a;
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (C:\Users\Carlo\--project--\node_modules\miniflare\dist\src\index.js:9178:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Mutex.runWith (C:\Users\Carlo\--project--\node_modules\miniflare\dist\src\index.js:3521:16) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

Node.js v22.6.0

The latest version without the error is 3.61.0, other versions like 3.62.0 give the error.
EDIT: Installing latest VS C++ Redistributable fixed the issue! 100% related to #6170

Working, Thanks a lot.

npm install<EMAIL_ADDRESS>i use this to solve this error. i tried install that https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170. but it seems need to restart windows system to work.


Switch order of general search and catalog number search

Upon feedback, switching the order of catalogNumber search and q search (General search) on the homepage. Scientific names of the form genus species appear to work well, so have used that as a placeholder.
More sophisticated work could be done in the future, however I think having search (even with limitations) is better than no search at all.

Closes #68


Windows Terminal Translation

Description
More easier way to translate Windows Terminal into more languages
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
Currently there is no easy method to translate terminal.
A clear and concise description of what you want to happen.
Easier way to help with translating terminal.

Thank you for your question. Unfortunately, the translation is currently an internal process that we don't have much control over. As such we don't support community translations at the moment. You can read #15288 for more details.
/dup #10667

This made me depreesed.

Thank you for your question. Unfortunately, the translation is currently an internal process that we don't have much control over. As such we don't support community translations at the moment. You can read #15288 for more details.
/dup #10667

Yes, it's not something we like either, but we currently lack the time and resources to change this. You can subscribe to #10667 to be notified when this changes.


Where is the dockerfile

Hi:
Where is dockerfile,  Is there any document about deployment.

https://github.com/edgedb/edgedb-docker


Thanks @antoaravinth for bringing this up. Myself I just wanted to use SW first as a POC then possibly something to include in a presentation.

I couldn't make it work by this method. The console always printed:
ServiceWorker registration failed:  DOMException: Failed to register a ServiceWorker for scope ('http://localhost:3000/') with script ('http://localhost:3000/sw.js'): The script has an unsupported MIME type ('text/html').
Thanks @antoaravinth for bringing this up. Myself I just wanted to use SW first as a POC then possibly something to include in a presentation.
@redixhumayun if you're still looking on how to do it in dev without changing the sw prod setup.
Create a simple sw register function in /src:
export default function LocalServiceWorkerRegister() {
    const swPath = `${process.env.PUBLIC_URL}/sw.js`;
    if ('serviceWorker' in navigator && process.env.NODE_ENV !== 'production') {
      window.addEventListener('load', function() {
        navigator.serviceWorker.register(swPath).then(function(registration) {
          // Registration was successful
          console.log('ServiceWorker registration successful with scope: ', registration.scope);
        }, function(err) {
          // registration failed :(
          console.log('ServiceWorker registration failed: ', err);
        });
      });
    }
}

Then in index.tsx import and call:
import * as React from 'react';
import * as ReactDOM from 'react-dom';
import App from './App';
import './index.css';
import LocalServiceWorkerRegister from './sw-register';
//import registerServiceWorker from './registerServiceWorker';

ReactDOM.render(
  <App />,
  document.getElementById('root') as HTMLElement
);

LocalServiceWorkerRegister();
//registerServiceWorker();

Then call your dev service worker file: sw.js (something different than prod) and put it in your /public folder.
npm start
Originally posted by @nick-gaudreau in https://github.com/facebook/create-react-app/issues/2396#issuecomment-385257044

Hi, closing this as accidental


Add unblock method for graceful shutdown

I hit the following problem and saw it in the issues too (#146) : how do you gracefully shutdown the server ? There is effectively no way of breaking out of incoming_requests() other than receiving a client request.
Rust favors message passing.  We can only pass messages between threads via channels to tell them to shut down on their own (or with synchronization primitives such as condvar, or with shared memory under lock). After some research, it turns out the standard library does blocking IO (ie the accept method on TcpListener used by tiny-http). There really is no way to break out of it except with a client request (or on error). This is already dealt with by a previous commit by @moises-silva (cde7981) : on object destruction we briefly connect to the server to unblock the thread stuck on accept. (side note : for async IO look for mio)
But a for loop on incoming_requests it still blocking. It's not stuck on accept but inside the message queue waiting on condvar for new client requests. This commit adds a special request variant that says to unblock the loop and return no client request (since there is none we just want to shutdown). I slightly modified the message_queue API (ie the pop method now returns an Option), which is internal. There are no changes on the public side, ie on server, except the addition of the unblock method that effectively unblocks one thread stuck in incoming_requests (or recv).
Since there is no breaking change to the public API, all existing code work as previously. The addition of unblock() allows to implement graceful server shutdown by calling it from another thread. Hopefully the two tests added make its usage clear. Let me know what you think.

Nice job, this may come handy for me soon-ish.

Nice job, this may come handy for me soon-ish.

Thanks!

why it not accepted?

I could use this as well.

Replaced by a rebased version in https://github.com/tiny-http/tiny-http/pull/184


Let the test suite work with "external" redis server

I am trying to package redis-client for Fedora, because it seems to be used by redis. In this attempt, I'd like to run the test suite with "Fedora" distributed version of Redis. Nevertheless, this seems to be pain ATM, because the whole test suite is built around the idea that Redis is downloaded and build.
https://github.com/redis-rb/redis-client/blob/7897ffefb4e8d1f4926bc4ad8d718fac2a4ad02f/test/support/redis_builder.rb#L35
Also, I wonder why toxiproxy, while it is IMHO similar case, is handled completely differently, via install-toxiproxy

the whole test suite is built around the idea that Redis is downloaded and build.

Yes, this is because we need to test against different versions of redis, and on many different platforms, so the easiest is to download and build it. That is the same with redis-rb, so not much change here.
I'm open a PR to make using an already existing redis an option (e.g. via ENV var or something).

I wonder why toxiproxy, while it is IMHO similar case, is handled completely differently, via install-toxiproxy

Because toxiproxy has readily available binaries for each platform, so no point compiling it (and it would require the go toolchain anyway).

the whole test suite is built around the idea that Redis is downloaded and build.

Yes, this is because we need to test against different versions of redis, and on many different platforms, so the easiest is to download and build it.

Right, but the version information is external to the test suite, so the build could also be external.

That is the same with redis-rb, so not much change here.

Just FTR. there were necessary essentially two changes to redis-rb:

fake the bin/build script:

# We are using packaged Redis, so provide just dummy Redis build script.
mkdir bin
echo '#!/usr/bin/sh' > bin/build
chmod a+x bin/build

Call make with some parameters:

make BINARY=$(which redis-server) REDIS_CLIENT=$(which redis-cli) BUILD_DIR='${TMP}'

To convince redis-client to use the preinstalled Redis, I think I need to do:
$ sed -i '/build_redis/ s/^/#/' test/test_helper.rb
$ sed -i '/def redis_server_bin/,/end/ s/redis_builder.bin_path/"redis-server"/' test/support/servers.rb

Comparing these two approaches, I think that the make approach is more flexible.

I'm open a PR to make using an already existing redis an option (e.g. via ENV var or something).

Thx. Given what I mentioned above, I think I would need to make the build process external to the test suite and therefore:

I am not sure it would really be acceptable
It would need quite some change
Is unfortunately not realistic I'd could afford to spend time to rework this

But I won't be mad if this is not a priority for you and therefore the ticket is closed. I'll keep using the workaround I mentioned above.

I wonder why toxiproxy, while it is IMHO similar case, is handled completely differently, via install-toxiproxy

Because toxiproxy has readily available binaries for each platform, so no point compiling it (and it would require the go toolchain anyway).

I understand and I agree, but again, the toxiproxy is external information to the actual test suite, while the Redis is baked in.

Right, but the version information is external to the test suite, so the build could also be external.

I don't follow what you mean here.

Thx. Given what I mentioned above, I think I would need to make the build process external to the test suite and therefore

Again I don't see what you mean here. What I'm suggesting is to have an env var to use whatever redis-server is in the path instead of building it from source.

the toxiproxy is external information to the actual test suite, while the Redis is baked in.

Again, no idea what you mean. We download the redis source, just like we download the toxiproxy binary.

Right, but the version information is external to the test suite, so the build could also be external.

I don't follow what you mean here.

https://github.com/redis-rb/redis-client/blob/8142b12b78216131ef2c145d3008102e64158891/.github/workflows/ci.yml#L53
Here you specify what Redis version is going to be used. Instead, there could have been provided redis executable, while the Redis would be setup in some step prior this one.

Thx. Given what I mentioned above, I think I would need to make the build process external to the test suite and therefore

Again I don't see what you mean here. What I'm suggesting is to have an env var to use whatever redis-server is in the path instead of building it from source.

the toxiproxy is external information to the actual test suite, while the Redis is baked in.

Again, no idea what you mean. We download the redis source, just like we download the toxiproxy binary.

Actually there are 3 external dependencies AFACIT and three distinct methods to obtain them:

Redis, downloaded via the redis_builder.rb
Toxiproxy downloaded via bin/install-toxiproxy
Hiredis downloaded by Rake task

It would be nice if:

all these tools used the same method for their setup.
something as basic as $PATH environment variable was used to pick e.g. the redis-server executable. I don't think there is any need for something such as redis_server_bin method.

Actually there are 3 external dependencies AFACIT and three distinct methods to obtain them:

Well. If there was easy to download redis-server binaries I'd use that. I won't be compiling toxiproxy from source just to be consistent with redis.
As for hiredis that's not part of CI, it's just an helper for me to upgrade the vendored hiredis, but that's a manual task.
Anyway, I think I stated the constraints, if you have PRs to make your life easier, I'll happily merge gems as long as they don't make my life harder.


[Confidential Ledger] [Data Plane] Make application claims parameter keyword-only in verify_receipt

Description
This PR makes the application_claims parameter keyword-only in verify_receipt as suggested by the SDK architects. It updates tests, samples, and README accordingly following these changes.
All SDK Contribution checklist:

[X] The pull request does not introduce [breaking changes]
[X] CHANGELOG is updated for new features, bug fixes or other significant changes.
[X] I have read the contribution guidelines.

General Guidelines and Best Practices

[X] Title of the pull request is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-confidentialledger


Log errors or show backtrace on failure

This refers to the intermittent exit status 1 issues like #237, #483.
I've been having the same issue after a fresh installation of Mac OS, chruby and a Rails 3.2.x app with vendored gems. I've been able to figure out (using dtruss) that the issues centered around the gem_is_bundled? calls for rake and method_source. In my case, the call to gem rake, {version} were trying to include the gem in the Ruby's gem set and not the ones from the vendored set. May be this is a chruby problem, but I'm not sure yet. The problem here is, it's not straight forward to see these simple errors without using a tracing program since nothing is being logged to the console except exit status 1. I tried piping out STRERR stream to the console and it looks like that's the only message that being printed out.
My question is, is there a debug flag/command line flag that shows the backtrace? If yes, I'll be happy to document it and open a PR. If not, can that be added?
It will be helpful in fixing simple issues like this gem mismatch error due to a faulty environment. For instance, there were warnings related to redefining constants like ROOT_PATH, BOOT_PATH etc. Fixing these sort of issues won't probably require any Go expertise and Ruby users can submit PRs if they understand the issues.

https://github.com/burke/zeus/issues/446#issuecomment-208882129 is kind of what I had in mind when I opened this issue.

This might help with debugging:
zeus --log ZEUS.LOG start
cat ZEUS.LOG


Add available_cpu to service_config in functions

Hi there, I was hoping to include CPU in the functions config as one needs at least 1 CPU to up the concurrent requests.
I made a pr but cannot push because of access issues.
It should be an easy win:
in main.tf:80
dynamic "service_config" {
    for_each = var.service_config != null ? [var.service_config] : []
    content {
      max_instance_count    = service_config.value.max_instance_count
      min_instance_count    = service_config.value.min_instance_count
      available_memory      = service_config.value.available_memory
      available_cpu         = service_config.value.available_cpu  #### addition

and variables.tf:113:
variable "service_config" {
  description = "Details of the service"
  type = object({
    max_instance_count    = optional(string, 100)
    min_instance_count    = optional(string, 1)
    available_memory      = optional(string, "256M")
    available_cpu         = optional(string, "1") #### addition

Hi @andrewwljackson! Thanks for your contribution.
To create a PR you'll need to fork the repo and then create the PR from your fork, instead of branching the repo directly. Also, if you are not currently covered under a CLA, please visit https://cla.developers.google.com/ to sign before submitting the PR. Once you do that we can take a look.

Hey @gtsorbo thanks so much for the response. I have signed the CLA, forked the repo and pushed a PR for your review, when you have time 👍