Additional Mango-based update handler / VDU functionality

This ticket is intended to gather ideas for what other sorts of update handler / VDU functionality we could add to Mango to provide a declarative replacement for JS-based update handlers and VDUs. This is intended as a "blue-sky" ticket to gather ideas that can be implemented simply in a declarative fashion.
From #1534, I wrote:

There are other proposals to provide similar/useful functionality (#1532, #1533, #1498) if the operator decides to run without a JS engine (#1513), plus I suspect there are thoughts about doing Mango-based update functionality to filter fields, as well as apply database schema enforcement (type and format checking) in a declarative fashion for a NoJS mode. Could your embedded RasPi update function be written declaratively? I assume you're adding info such as incoming IP address, central timestamp, etc. which I could see being done automatically quite easily. This is a use case we can accelerate without the use of JS readily; we just need to agree on an API and how to write it down in a JSON blob.

Extracting:

Add datetime stamp (#1533)
Add IP address from incoming host, or other fields from the req object
Add additional content based on fields in the req object

Perhaps a lookup table that maps a req field value to a key:value pair (or JSON Patch) to insert?

Filter out (blacklist) or only allow (whitelist) certain fields (lists) - this is partial JSON schema support
Type-checking (field type is string, field date is ISO datetime|UNIX epoch, etc.)
Field validation (format-checking, i.e. string must match a regex like "$###.##" or an integer must be within a certain range)
Consider using output of another Mango index/query for validating a field? For instance, a Mango query of documents that are of type source and extracting the field ip_address, then only allowing documents to come through that have a matching req.ip_address (for example).

Same as above, but to implement the lookup table. Example: look up source's IP address, auto-add name of sensor which is in the first document that matches in the Mango index

Got to thinking more about this one in the shower. Here's a sample Mango-like document structure for a combined VDU/update handler that would capture all of the above:
{
  "queries": [
    {
      "name": "sensor_name",
      "selector": {
        "type": "sensor",
        "ip_address": "$doc.ip_address"
      },
      "fields": ["name"],
      ...
    }
  ],
  "fields": {
    "whitelist": ["type", "datetime", "ip_address", "station_name", "temperature", "RH%", "rain_gauge", "wind.speed", "wind.direction", "light", "battery.voltage", "battery.current", "line.voltage", "line.current", "solar.voltage", "solar.current", "register_total"],
    "blacklist": ["battery.wattage", "rain_gauge.*"],
    "formats": {
      "type": ["sensor_reading"],
      "datetime": {
        "$or": {
          "$format": "$iso8601",
          "$format": "$unixepoch",
          "$regex": "(\\d{2})-(\\d{2})-(\\d{2}) (\\d{2}):(\\d{2}):(\\d{2})"
        }
      },
      "battery.voltage": "$float",
      "battery.current": "$float",
      "register_total": { "$regex": "^\\$\\d{1,9}\\.\\d{2}$" },
      "wind.direction": {"$or": ["N", "NE", "E", "SE", "S", "SW", "W", "NW"]}
      ...
    }
  },
  "patch": [
      { "op": "add", "path": "/", "value": { "name": "$query:sensor_name.name" } },
      { "op": "move", "from": "/ip-address", "path": "/ip_address" },
      { "op": "add", "path": "/", "value": { "server_datetime": "$server_time.iso8601 } },
      ...
  ]
}

Comments:

This runs a Mango query up front to get any documents with "type": "sensor" that match the IP address of the incoming request. (Assumes that the $req object has that value, not sure we pass that thru to VDUs right now...)
There's then a field presence check. In a real situation, you would probably only have one of fields.whitelist and fields.blacklist.
Field values/formats are then checked, some just for general structure, one by regex, one by list of acceptable values. The output of a Mango query could be used as input to this, too. (An aside: Mango aggregations could be really useful here, for instance to reduce a query to a single list of acceptable values. See #1254.)
Documents that didn't match "type": "sensor_reading" or any of the other format checks would fall through to the next whatever-we-call-this-thing. If all failed, the document would be rejected.
Maybe we add a "$format": "$datetime" that includes all the common datetime formats?

Just some food for discussion.

IMO the patch list better be named transform and look like
transform:[
  {
    selector:{  // Mango selector for list of actions
      type: { $neq: "whatever"}
    },
    actions: {  // List of actions
      ["stop"]
    }
  },
  // Next item, used if we didn‘t stop processing
  {selector:{ stamp: { $format:'Int', $gt:<PHONE_NUMBER>123}},
  actions: {
    ["set",  ".ip",  ":peer"   ],
    ["swap", ".a.0", ["a", "1"]],
    ["del",  ".x.y.z"          ]
  }}
  //...
]

Actions are pretty self-explanatory, so no need to use obj keys. Objects as .actions members may be used later for syntax extensions or nesting.
This also replaces .fields.format typecheck making it more flexible. Typechecks just move to actions list member .selector prop.
Also syntax "battery.voltage": "$float" in fields seems somewhat ambiguous. Using proposed syntax it should be "battery.voltage": {"$format": "Float"}. $ marker before formats/types seems to be excessive, omitting it in favor of uppercasing type tag reads better.
It all seems unexpectedly reasonable. I’ll try to write down some of our _updates in this way, to compare readability and to understand other json-induced benefits/penalties.
And I couldn‘t comprehend what .queries field supposed to do. Can you please give a hint?

Sorry, I hit submit too quickly. The $ before operators is mimicing the Mango syntax, to distinguish operators from operands. You're right that in some places, where the value is expected to be a format (like the float check) we can probably drop the $. As for the format, it's already inside the list for the top-level formats key, so it wouldn't need an additional {"$format":"float"} in my approach, since my approach is intentionally keeping the patch section JSON Patch compatible.
As for queries, the idea is you could run a Mango query before applying the VDU/update handler, then use that information later on. See the first line in the patch entry for use of the lookup to convert an incoming sensor's IP address to a station name. The returned result could also be used in the validator section, for instance, to look up the current list of allowed wind direction values or something.
The pre-update-Mango-query stuff is speculative; there may well be pushback from the db core team on making update functions a little too clever and slow since they're now performing a read before a write. We'll see. I think the proposal is valuable even without that specific functionality.

I like this idea, and especially the ability to use multiple docs of this format to enforce rules such as "only users with role sensor are able to add/modify documents of type sensor. It's not fully-fledged per-doc auth since this only is traversed on the write path, but it might be a way forward for the read-path too (if people are willing to accept the massive performance penalty it'll invoke).
The queries idea was blue sky, happy to break it into a separate issue so it doesn't get lost when we implement this one.
I'm flexible on what lives where in the actual doc, would like to see some other opinions as well.
I would say that for authorisation, since you didn't break things out into separate selector and action sections, we use $throw to ensure we don't overlap any tests against a real document key named throw. We'll need to work out escaping just in case someone DOES have a key named $throw, same for the other sections as well.
The alternative is to prefix all document fields with $doc but I think this makes things needlessly verbose, don't you?

yeah not a fan of $doc prefix, but $throw works fine.
That might dovetail into my next proposal (that I’ll open a new ticket for), to add string manipulation funs to Mango, those then would follow the same lead, say $strlen(field.sub), but let’s keep that definitely separate from this proposal ;D

@janl should your JSON snippet be (i..e, with the schema and authorization top level fields):
{
    "schema": {
        "whitelist": [
            "type",
            "datetime",
            "others....."
        ],
        ...
    },
    "authorization": [
        {
            "author": { "$eq": "$userCtx.name" },
            "throw": "you can’t update other user’s docs."
        }
    ]
}

Also, I used American spelling for "authorization".
Suggestion:

I think for clarity, splitting out the selector and action in the authorization field as @wohali suggests means you can avoid the ambiguity of field name vs. processing instruction. Collapsing them together feels confusing to me.

Questions:

What would happen when replicating to older db versions that don't understand some part of the validation (e.g., didn't understand formats part of schema)? Be lenient (ignore bits not understood) or strict (fail validation when can't process the whole set of instructions)?
There's an information leak possible: write-only users can discern document shape by observing error messages for schema.

Perhaps an optional throw clause which would allow the user to override default error to prevent this leakage.

@mikerhodes good catch, that's a typo!

@mikerhodes asks:

What would happen when replicating to older db versions that don't  understand some part of the validation (e.g., didn't understand formats part of schema)? Be lenient (ignore bits not understood) or strict (fail validation when can't process the whole set of instructions)?

Idea 1: Maybe we need a version field, regardless of what we do with this, if not specified we assume it's the version of whatever the current runtime is
Idea 2: Maybe we need a "fail": "closed|open" setting per-VDU
Idea 3: Maybe we need a server setting in local.ini to toggle the same thing
The latter 2 come from electronic door locks that generally come with a user-configurable setting for this.

There's an information leak possible: write-only users can discern document shape by observing error messages for schema. Perhaps an optional throw clause which would allow the user to override default error to prevent this leakage.

Well, in Apache CouchDB, there are no such things as write-only users to my knowledge. Are you talking about a Cloudant-specific thing, or something that might come in with #1504 ?
I was imagining that if any of the tests failed (pre-@janl's change) a generic response would be provided, along the lines of document failed validation, maybe including the name of the whatever-we-call-this to point a finger, but not explictly including the precise reason for failure. I like the idea of a $throw.default to override that message if you want, but I'm not sure it does much?
The other option would be to provide a "debug": true/false boolean toggle that would include precise info about the reason for a document's failure. We've done a poor job of helping users debug their JS functions in the past. Putting the control over debugging a Mango-VDU in the hands of the developer would be a big step up in my opinion.
Thanks for the discussion!

Cloudant has write-only, but I did think that it'd likely come in with any access rewrite as it's definitely a useful thing.

I‘ve tried to re-write several real simple _update fns with proposed syntax. My observations:

schema, whatever implementation is, better have conditionals/guards
update requires conditionals/guards even more: VDU results commute, so you can have many VDUs in different ddocs; this is not true for updates – without conditionals we need as many updates (and endpoints) as number of schemas, which is bit messy and unsafe from integrity POV
transform/patch lists of actions also require guards: schema match doesn‘t automatically mean plain list of actions is applicable
JSON patch is definitely hard to read, too verbose; for long lists repeated key names look as an excessive markup noise
constantly switching between dot notation of Mango paths and slash notation of JSON patch is a direct way to errors
it all needs sandboxed testing tools, entire syntax is not easy to read and, unlike Mango, errors are immediately destructive for incoming data.

making update functions a little too clever and slow

AFAIK more risk is to make them dumb and cryptic as old-style rewrites )
Here is a set of existing tools of the sort, hope it can be a source further inspiration https://stackoverflow.com/questions/1618038/xslt-equivalent-for-json/49011455#49011455

schema, whatever implementation is, better have conditionals/guards

@ermouth do you have an example?

@janl latest json schema has if/then/else

I'll suggest the obvious: that the guards be mango selectors.
I think "condition" may be the right term for the authorization's actual business logic (might be a better term from the authorization literature, but it escapes me right now).
Combining the suggestion to split out the authz section into three fields:
{
    "authorization": [
        {
            "guard": {"type": { "$eq": "post" }},
            "condition": {"author": { "$eq": "$userCtx.name" }},
            "throw": "you can’t update other user’s docs."
        },
       {
            "condition": {"type": {  "$in": ["post", "author"] }} ,
            "throw": "documents must be type 'post' or 'author'."
        },
    ]
}

@mikerhodes I already suggested exactly same approach (using Mango selectors as guards), see above, however it was assumed too clever. Nice to see this obvious and practical way came not only in my head.
What is the difference between guard and condition in you example? And why special authorization field needed; I mean why special field if a list of guard/actionList pairs may be used without pinpointing each pair semantic meaning?

@ermouth I think I misunderstood what you were proposing...probably a language barrier. It's clearer to me now.
I think the guard is checked first, to make sure that the document would even have the field in question, and then the condition is checked. This would translate to JS in such a way:
if (doc.type === "post") {
  if (doc.author != userCtx.name) {
    throw("you can't update other users' docs.")
  }
}

Am I right @mikerhodes ?

@wohali Yes, that's the basic logic. I think my condition logic is the wrong way around, because I would say that the throw happens if condition is false rather than if condition is true.
if (doc.type === "post") {   // i.e., "if <guard condition>"
  if (! (doc.author == userCtx.name)) {  // i.e., "if not <condition>"
    throw("you can't update other users' docs.")
  }
}

I can see that you could combine the guard and the condition into a single clause quite easily given they are both Mango selectors. I just find that the logical distinction of "the types of thing this authorisation decision applies to" (guard) and "the authorisation condition itself" (condition) makes things more clear.

@garrensmith That's very much appreciated. I'd love for some pointers on which files will contain pertinent code, functions I might have to edit or copy, etc. Otherwise I'm just stumbling through the source and hitting my local couch with requests, hoping the responses change in response to my actions.

I'm going to try and leave some ideas on how to implement this. The one thing I've noticed is that this is quite a large amount of work, so I think try and break it up into smaller usable PR's. I also think it is worth creating a RFC for this with all the information on this and add in the gist so that its in 1 central place.
I would start on the transform section first. That section could possibly be used in the mango query section. We could take a document we want to index and then transform it before adding it to the index. This has been a requested feature.
For $transform, $schema and $authorization section
All of the mango syntax manipulation lives here https://github.com/apache/couchdb/blob/master/src/mango/src/mango_selector.erl
I think it might be best to create a new mango_vdu_selector or something file that uses parts of mango_selector and does all the validation and transformation of a document based on the syntax.
Saving/creating/getching of VDU's:
The CRUD for a mango index is here https://github.com/apache/couchdb/blob/master/src/mango/src/mango_idx_view.erl
Again I would probably create another file e.g mango_vdu and leverage mango_idx_view to do all the retrieving of the vdu's.
I hope that helps a little.

I swear I thought I had mentioned this already, but apparently not on this thread.
I’d leave the transform bits out of this proposals on focus on the VDU part: validate that a doc looks like what you want it to be and comes from someone you want it to be.
I’d leave mango-like syntax for doc transformation to #1559.

+1 to reducing the scope of this work.

From: Jan Lehnardt<EMAIL_ADDRESS>Sent: Wednesday, February 20, 2019 12:57 PM
To: apache/couchdb
Cc: garren smith; Mention
Subject: Re: [apache/couchdb] Additional Mango-based update handler / VDU functionality (#1554)
I swear I thought I had mentioned this already, but apparently not on this thread.
I’d leave the transform bits out of this proposals on focus on the VDU part: validate that a doc looks like what you want it to be and comes from someone you want it to be.
I’d leave mango-like syntax for doc transformation to #1559https://github.com/apache/couchdb/issues/1559.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/apache/couchdb/issues/1554#issuecomment-465526805, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAK9Alq3mMGDv4fIXGZ8FmeiK12tIDM3ks5vPSo3gaJpZM4V5aai.


Fix routing spec scaffold format

When I scaffold an User model in Rails 5 API application, I get this in spec/routing/users_routing_spec.rb:
require "rails_helper"

RSpec.describe UsersController, type: :routing do
  describe "routing" do

    it "routes to #index" do
      expect(:get => "/users").to route_to("users#index")
    end

    it "routes to #show" do
      expect(:get => "/users/1").to route_to("users#show", :id => "1")
    end

    it "routes to #create" do
      expect(:post => "/users").to route_to("users#create")
    end

    it "routes to #update via PUT" do
      expect(:put => "/users/1").to route_to("users#update", :id => "1")
    end

    it "routes to #update via PATCH" do
      expect(:patch => "/users/1").to route_to("users#update", :id => "1")
    end

    it "routes to #destroy" do
      expect(:delete => "/users/1").to route_to("users#destroy", :id => "1")
    end

  end
end

Preferably, it should look like this:
require "rails_helper"

RSpec.describe UsersController, type: :routing do
  describe "routing" do
    it "routes to #index" do
      expect(:get => "/users").to route_to("users#index")
    end

    it "routes to #show" do
      expect(:get => "/users/1").to route_to("users#show", :id => "1")
    end

    it "routes to #create" do
      expect(:post => "/users").to route_to("users#create")
    end

    it "routes to #update via PUT" do
      expect(:put => "/users/1").to route_to("users#update", :id => "1")
    end

    it "routes to #update via PATCH" do
      expect(:patch => "/users/1").to route_to("users#update", :id => "1")
    end

    it "routes to #destroy" do
      expect(:delete => "/users/1").to route_to("users#destroy", :id => "1")
    end
  end
end

This PR aims to solve this issue.

Thanks ❤


HBASE-24132 Upgrade to Apache ZooKeeper 3.5.7

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 47s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 22s
master passed

+1 :green_heart:
compile
3m  0s
master passed

+1 :green_heart:
shadedjars
4m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 23s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 10s
the patch passed

+1 :green_heart:
compile
3m  4s
the patch passed

+1 :green_heart:
javac
3m  4s
the patch passed

+1 :green_heart:
shadedjars
4m 53s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 30s
the patch passed

_ Other Tests _

-1 :x:
unit
12m 13s
root in the patch failed.

48m 40s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux bb29c5aa681b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 80d4a09ddc

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/testReport/

Max. process+thread count
564 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
3m  7s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 56s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
7m 39s
master passed

+1 :green_heart:
checkstyle
3m 13s
master passed

+1 :green_heart:
spotbugs
18m 52s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 27s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
8m  5s
the patch passed

+1 :green_heart:
checkstyle
3m 14s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  2s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
16m 20s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2.

+1 :green_heart:
spotbugs
17m 53s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 39s
The patch does not generate ASF License warnings.

90m 53s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle xml

uname
Linux ba035cef77a7 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 80d4a09ddc

Max. process+thread count
84 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 24s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
8m 38s
the patch passed

+1 :green_heart:
compile
4m  0s
the patch passed

+1 :green_heart:
javac
4m  0s
the patch passed

+1 :green_heart:
shadedjars
5m 30s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 16s
hbase-zookeeper in the patch failed.

-0 :warning:
javadoc
0m 39s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 19s
root in the patch failed.

_ Other Tests _

-1 :x:
unit
125m 50s
root in the patch failed.

172m 52s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 1f2ba9752ea6 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / 80d4a09ddc

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-root.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-root.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/testReport/

Max. process+thread count
4480 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/1/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Trigger the build again to see if it could pass this time.
And for the jline change, I'm fine with doing it here or in another issue.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 18s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 43s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
6m  1s
master passed

+1 :green_heart:
checkstyle
2m 44s
master passed

+1 :green_heart:
spotbugs
16m  8s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 19s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
6m  2s
the patch passed

+1 :green_heart:
checkstyle
2m 40s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  2s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
12m 33s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2.

+1 :green_heart:
spotbugs
16m 51s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 37s
The patch does not generate ASF License warnings.

74m  9s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
dupname asflicense spotbugs hadoopcheck hbaseanti checkstyle xml

uname
Linux 365ffd74d799 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c383bd1bb3

Max. process+thread count
83 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 31s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 49s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 49s
master passed

+1 :green_heart:
compile
3m 18s
master passed

+1 :green_heart:
shadedjars
5m  3s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 33s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 19s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 40s
the patch passed

+1 :green_heart:
compile
3m 21s
the patch passed

+1 :green_heart:
javac
3m 21s
the patch passed

+1 :green_heart:
shadedjars
5m 13s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 30s
the patch passed

_ Other Tests _

-1 :x:
unit
207m 59s
root in the patch failed.

246m 59s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3a1eca58a4d0 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c383bd1bb3

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/testReport/

Max. process+thread count
2738 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
6m 56s
the patch passed

+1 :green_heart:
compile
4m 12s
the patch passed

+1 :green_heart:
javac
4m 12s
the patch passed

+1 :green_heart:
shadedjars
6m 17s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 15s
hbase-zookeeper in the patch failed.

-0 :warning:
javadoc
0m 48s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 20s
root in the patch failed.

_ Other Tests _

-1 :x:
unit
207m 56s
root in the patch failed.

248m 46s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 3ed9ea4eb104 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / c383bd1bb3

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-root.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-root.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/testReport/

Max. process+thread count
2730 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/2/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 29s
Maven dependency ordering for branch

-1 :x:
mvninstall
5m 43s
root in master failed.

+1 :green_heart:
checkstyle
3m 13s
master passed

-1 :x:
spotbugs
9m 44s
root in master failed.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for patch

-1 :x:
mvninstall
5m 20s
root in the patch failed.

+1 :green_heart:
checkstyle
2m 52s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  3s
The patch has no ill-formed XML file.

-1 :x:
hadoopcheck
2m 47s
The patch causes 16 errors with Hadoop v2.10.0.

-1 :x:
hadoopcheck
5m 40s
The patch causes 16 errors with Hadoop v3.1.2.

-1 :x:
spotbugs
9m 42s
root in the patch failed.

_ Other Tests _

+1 :green_heart:
asflicense
0m 48s
The patch does not generate ASF License warnings.

53m 32s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
dupname asflicense xml spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux 18ee689fb500 4.15.0-74-generic #84-Ubuntu SMP Thu Dec 19 08:06:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / eb7df0498c

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/branch-mvninstall-root.txt

spotbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/branch-spotbugs-root.txt

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/patch-mvninstall-root.txt

hadoopcheck
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/patch-javac-2.10.0.txt

hadoopcheck
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/patch-javac-3.1.2.txt

spotbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-general-check/output/patch-spotbugs-root.txt

Max. process+thread count
83 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f) spotbugs=3.1.12

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Can 3.5.7 client talk to a 3.4 ensemble and vice-versa? Are their compatibility issues? Would be good to note in release note for this JIRA. Thanks.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 30s
Maven dependency ordering for branch

-1 :x:
mvninstall
4m 18s
root in master failed.

-1 :x:
compile
1m 51s
root in master failed.

-1 :x:
shadedjars
3m 54s
branch has 16 errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 33s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

-1 :x:
mvninstall
4m 21s
root in the patch failed.

-1 :x:
compile
1m 55s
root in the patch failed.

-0 :warning:
javac
1m 55s
root in the patch failed.

-1 :x:
shadedjars
4m  9s
patch has 16 errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 38s
the patch passed

_ Other Tests _

-1 :x:
unit
144m 39s
root in the patch failed.

176m 14s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 8fcd1c3e13bc 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / eb7df0498c

Default Java
1.8.0_232

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/branch-mvninstall-root.txt

compile
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/branch-compile-root.txt

shadedjars
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/branch-shadedjars.txt

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/patch-mvninstall-root.txt

compile
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/patch-compile-root.txt

javac
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/patch-compile-root.txt

shadedjars
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/patch-shadedjars.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/testReport/

Max. process+thread count
4152 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 19s
Maven dependency ordering for patch

-1 :x:
mvninstall
5m  6s
root in the patch failed.

-1 :x:
compile
2m 25s
root in the patch failed.

-0 :warning:
javac
2m 25s
root in the patch failed.

-1 :x:
shadedjars
4m 55s
patch has 16 errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 15s
hbase-zookeeper in the patch failed.

-0 :warning:
javadoc
0m 41s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 18s
root in the patch failed.

_ Other Tests _

-1 :x:
unit
156m 47s
root in the patch failed.

188m 59s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ae103cff2f7f 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / eb7df0498c

Default Java
2020-01-14

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-mvninstall-root.txt

compile
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-compile-root.txt

shadedjars
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-shadedjars.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-root.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

mvninstall
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-mvninstall-root.txt

compile
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-root.txt

javac
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-compile-root.txt

shadedjars
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-shadedjars.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-root.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/testReport/

Max. process+thread count
3935 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/3/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
2m 22s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ master Compile Tests _

+0 :ok:
mvndep
0m 44s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
6m  4s
master passed

+1 :green_heart:
compile
3m 22s
master passed

+1 :green_heart:
shadedjars
4m 43s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 41s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 32s
the patch passed

+1 :green_heart:
compile
3m 19s
the patch passed

+1 :green_heart:
javac
3m 19s
the patch passed

+1 :green_heart:
shadedjars
5m 11s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
3m 36s
the patch passed

_ Other Tests _

-1 :x:
unit
12m 17s
root in the patch failed.

53m 11s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 25bb56710c81 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ac4e94e868

Default Java
1.8.0_232

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk8-hadoop2-check/output/patch-unit-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/testReport/

Max. process+thread count
564 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 30s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

+0 :ok:
mvndep
0m 45s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 12s
master passed

+1 :green_heart:
checkstyle
2m 14s
master passed

+1 :green_heart:
spotbugs
13m  1s
master passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 20s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 13s
the patch passed

+1 :green_heart:
checkstyle
2m 14s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
xml
0m  3s
The patch has no ill-formed XML file.

+1 :green_heart:
hadoopcheck
10m 49s
Patch does not cause any errors with Hadoop 2.10.0 or 3.1.2.

+1 :green_heart:
spotbugs
13m 45s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 55s
The patch does not generate ASF License warnings.

62m 36s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
dupname asflicense xml spotbugs hadoopcheck hbaseanti checkstyle

uname
Linux e49d12d3dd24 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ac4e94e868

Max. process+thread count
93 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
6m 34s
the patch passed

+1 :green_heart:
compile
3m 48s
the patch passed

+1 :green_heart:
javac
3m 48s
the patch passed

+1 :green_heart:
shadedjars
5m 26s
patch has no errors when building our shaded downstream artifacts.

-0 :warning:
javadoc
0m 15s
hbase-zookeeper in the patch failed.

-0 :warning:
javadoc
0m 48s
hbase-server in the patch failed.

-0 :warning:
javadoc
0m 19s
root in the patch failed.

_ Other Tests _

+1 :green_heart:
unit
171m 57s
root in the patch passed.

210m 56s

Subsystem
Report/Notes

Docker
Client=19.03.8 Server=19.03.8 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/1453

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux ed87587712d5 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
master / ac4e94e868

Default Java
2020-01-14

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-root.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/branch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-zookeeper.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-hbase-server.txt

javadoc
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/artifact/yetus-jdk11-hadoop3-check/output/patch-javadoc-root.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/testReport/

Max. process+thread count
5040 (vs. ulimit of 10000)

modules
C: hbase-zookeeper hbase-resource-bundle hbase-server . U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-1453/4/console

versions
git=2.17.1 maven=(cecedd343002696d0abb50b32b541b8a6ba2883f)

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Hi @saintstack , I just noticed your question on the jira, and saw you also asked here: yes, 3.5.7 client is able to communicate with an 3.4.x ensemble. But new features should not be used.


Add a refresh button to HTML Source window

The HTML Source window has one flaw: it has to be opened at least two times to update the source text box after each change.
A simple solution would be to add a refresh button to the HTML Source window. The refresh button would then call the initialize() method in HTMLSource class to manually get the new source code and set it to the text box.

Fixed in dev-html branch.


tensorflow r1.0.0 needs numpy 1.11.0

Hi! I found that tensorflow r1.0.0 needs numpy 1.11.0 as a requirement when setting up a fresh install.

Thanks for this!


Fuzzing add seed, new target and remove bloat

Description
Add more go-fuzz tests, add input seed and remove bloat.
Bug found:  https://github.com/pion/dtls/issues/591
Run:
go test -fuzz=FuzzUnmarshalBinary       $(pwd)
go test -fuzz=FuzzUnmarshal             $(pwd)/pkg/protocol/extension
go test -fuzz=FuzzDtlsHandshake         $(pwd)/pkg/protocol/handshake
go test -fuzz=FuzzRecordLayer           $(pwd)/pkg/protocol/recordlayer
go test -fuzz=FuzzUnpackDatagram        $(pwd)/pkg/protocol/recordlayer

Fantastic, thank you so much @0x34d
Can you fix the golangci-lint errors? If you don't feel comfortable doing it I can help!

@Sean-Der ping, can you rerun the workflow?

@0x34d you are in the org now so you can run yourself :)
sorry for slowing you down

ping for merge @hasheddan @stv0g @Sean-Der

I think it would be nicer to put the fuzz corpus into files. The fuzzer reada them automatically from testdata/TestName

I think it would be nicer to put the fuzz corpus into files. The fuzzer reada them automatically from testdata/TestName

Done https://github.com/pion/dtls/pull/592/commits/816e08482150cc42b54c5988a158049cc73937af and leave others as they are.

ping

Merged with https://github.com/pion/dtls/commit/d7964378674c5a64b6a7f9222f1ff6a8209885dc
Thank you so much @0x34d sorry this didn't happen quicker


[Bug]-[1500]:Upon adding a new JSObj/Query/Blank API's - EntityExplorer should show the new item in the expanded tree

Is there an existing issue for this?

[X] I have searched the existing issues

Description
.png:

Steps To Reproduce

Create a new application
Add a new JSObject/Query/Blank API
User should be able to see the item added in the left side tree - as a confirmation that new item being created is added [as visible before]
Once user expands/collapses the Queries/JS or DataSources sections - then that state should be preserved upon different navigations/page refreshes etc.,
For older apps - the state can be preserved as decided by user
This bug addresses only the experience during a new application creation

Public Sample App
No response
Version
Cloud Release v1.6.15

Stats

Stat
Values

Reach
3000

Effort (months)
1

@arunvjn On an existing application -> Adding a new Page or New Application -> First page - Does not still have the Queries/JS open & so no indication of a newly added Api/Query/JSObject to the user.
Point 6 from this bug is not addressed. Hence reopening the bug.

[ ] when we add Queries/Datasource and hit on the back button then it is not navigating back to the canvas instead it opens the  datasource page. Please refer the video attached:- https://jIju8JbmWA.vmaker.com/record/CAuXSLz5ZiZPEqDy

@hetunandu

[ ]  when we add Queries/Datasource and hit on the back button then it is not navigating back to the canvas instead it opens the  datasource page. Please refer the video attached:- https://jIju8JbmWA.vmaker.com/record/CAuXSLz5ZiZPEqDy
[ ]  Getting "Internal server error while processing request" when clicked on the Save and Authorize button from the datasource page. Please refer the attached video:- https://jiju8jbmwa.vmaker.com/record/Fy3Hsamk4MyOoEwD

These issues are unrelated to the change and already existing in prod

This issue is fixed verified it on the DP url.


HttpsPortDynamic is automatically set to false

I have test configured with @AutoConfigureWireMock(port = 0). However, the context is still marked as dirty as per #883 , because httpsPortDynamic has been set to false. I tried debugging where this value comes from, but I can only find the information [...] origin = "wiremock.server.https-port-dynamic" from property source "wiremock"]. No other (signifcant) property file is used, nor are environment variables set.
The spring-cloud-contract-wiremock version is 2.1.1.RELEASE.

I've added a comment to #883. If the context is refreshed as part of the test framework then the HttpsPortDynamic property can be reset to false. I've submitted a PR to resolved this scenario.

New PR for fix: https://github.com/spring-cloud/spring-cloud-contract/pull/1028

@boothen is working on the fix.

New PR with fix: #1040

Should be fixed by #1048


fix: workaround for sourcemap warnings

Description
Closes #140
The sourcemaps fix in Vite is not enough for us because that id parameter contains the querystring ?no-proxy, and it breaks the sourcemap.
This PR implements a workaround on our side until it is fixed in Vite (I'll open PRs there soon).
Apart from that, looks like react-ssr-prepass soucemap is broken so this also ignores it. I tried to read the proper sourcemap from a file next to the source code, but looks like it crashes in Jest and build... that's why Vite is ignoring it, probably.

Before submitting the PR, please make sure you do the following:

[x] Add your change under the Unreleased heading in the package's CHANGELOG.md
[x] Read the Contributing Guidelines
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
[ ] Update docs in this repository for your change, if needed

PR in Vite here: https://github.com/vitejs/vite/pull/5760
Not sure if it will be approved, though, perhaps breaks something else.


Possibly add talking Avatar?

It would be more engaging if we could have a talking avatar. There are some open-source models and non-free ones as well.

@ling-k do you have any examples?
Part of why I'm hesitant is that I don't see them at the same level of maturity, but happy to look at them.

@natolambert I have tried the Azure AI one. It works well but not free.
https://speech.microsoft.com/portal/talkingavatar
Now, there are several avatars we can select. I think they will allow users to upload their own avatar and then retrain the generation model.

Something like the video below is also pretty good. Some different avatars. Not sure what they have used.
https://www.youtube.com/shorts/RzMMPUY09SQ

Unsurprisingly, most of the APIs look pretty expensive for my amount of content (~30-60min/month), and many don't allow me to bring my own audio file yet. I'm more invested in having it sound pretty close to me for now (which it is doing surprisingly well at) than the video now.
I agree it's kneecapped on YouTube essentially being a audio only file.


Coke/clean spell

The problem
Words don't get cleared out of the dictionary files, which may be needed in a few cases, like

bug fixes in xt/aspell.t mean we no longer have to mark something as a word
aspell itself gets smarter and fewer words have to be marked
usage of a word is removed from the docs

Solution provided
Script to test if it's OK to remove each word. Does a little more work than necessary.
Update dictionary files to remove all extras (214).
PR so someone with a different aspell installation can verify there's nothing weird about my local english dictionary.

Good idea. A couple of things:

The script seems overzealous. "Rakudo" has been removed from xt/words.pws in 94702ee, yielding 60/376 test failures.
I wonder whether we want to whitelist things irrespective of their presence in the documentation to prevent churn.

For example, you've removed "radians", "recursing", "refactor", "searchable"—if those show up again in documentation we'd need to re-whitelist them. Removal seems counterproductive.
Proposal: enforce the distinction between codewords (code.pws) and English dictionary extensions (words.pws) more robustly, apply util/clean-spell to the codewords file alone.

words.pws can of course be pared down first, perhaps with your script.

Thoughts?

In principle, I think this is a great idea. But it means we're adding a new utility to the perl6/doc repository, which is going to be downloaded every single time someone installs the module, and this is something (along with pretty much the rest of this directory) that is interesting mostly for us, as in people who are actively working on the repo.
So I'm all for accepting this if it works, but I'm also all for maybe spinning all spelling-related stuff to a new repo. We could even set up Travis to run periodically over docs, and send us a report, even automatically create an issue that we would work against. What do you think?

Regarding sizes, the new script file is dwarfed by the list of words we're already tracking; Making a slim download of just the docs as a release seems like a solution to this problem.
Regarding failures - I apparently had a local ~/.aspell.en.pws which had a few entries, will remove that file and clean up with a force push.
FYI, "searchable" is removed because it's in the dictionary and doesn't need to be in the list. You can see it's still present in doc/Language/about.pod6 and not triggering a failure.

It's not so much about sizes, it's about having something else in the repo, with commit history, maintenance commitments, and so on. Having all the things related to spelling check, in which only maintainers are interested, is a bit too much for the regular user who just wants to download the documentation. For the time being I think it's OK to accept the PR, but all the spelling-related things are a serious candidate for spinning off the repository, at least IMHO.

What's the ticket for the issue of user downloads of docs? Would like to add some notes there.

whitespace fixed

The two remaining issues I see based on comments
Might have to add words back in - this is an ongoing battle regardless; updates to the dictionary files are made quite often. We won't have to go through this exercise of cleaning very often. If we want to run it again with just code.pws, that's a simple modification to the script, we can do that.
Regarding the thread about utilities moving outside the repo, that can be handled in the context of #2542.
Merging, thanks.


Adding examples for Active Storage Loader and Postgres Window Loader

I love when a project has a ton of examples that can be used and extended. Example: https://github.com/zeit/next.js/tree/canary/examples
I wanted to add 2 examples that solve somewhat challenging batch issues:

Loading has_many relationships where you want the first N records. This can be accomplished using window functions in Postgres.
Loading Active Storage attachments (can often produce 2N + 1 queries).

👋 hey @leighhalliday, lost track of this but I agree it's useful to have more examples. I'm not going to verify these, but they look good so I'll merge.


docs: troubleshooting: explain npm dedupe

RE: #1535

Coverage remained the same at 100.0% when pulling 660c7d6c819a353961faedb8eacbdc4037584947 on stephenplusplus:spp--1535 into 069d82775a091dacfe9e8c3fb103bc4aee0ad895 on GoogleCloudPlatform:master.


Typescript does not identify when a property can be undefined due to a safe operator being used

🔎 Search Terms
"safe navigation operator", "optional chaining"
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about our issue.

⏯ Playground Link
https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgPICMBWyDeAoZZABzijgFsAuZAZzClAHMBuPAXzzzAE8iUNMqKADkA9mGQBeNFmQAfZAFcQAEwgxQEFazwAbCBJijR1AULFgdCUSBqj9AOl2jGACiOiA-A5JlyASmZkAHpg5B4+GgQGIgkAaxBRAHcacIALOAlfCmRrRV0VZHQUOgYQRmRRKCVVdU1CtOgIBwc8a1t7Zuc3D29s8gcaXWAkV39AkLCIiCiYiRo00XzC63IiXThQZEaoCAAaYlIc8jhuIpRlNQ0QLWQ4VWREiThaeiYHIA
💻 Code
interface Obj {
  param: string;
}

type ObjOrNot = Obj | undefined;

let foo: ObjOrNot;

console.log(foo?.param); // typescript knows that param could be string or undefined here.
console.log(foo?.param.slice()); // typescript should complain here, param may be undefined and not a string, but it says it is a string.

🙁 Actual behavior
typescript allows .slice() to be called on param
🙂 Expected behavior
typescript should give an error when calling .slice() on param because param may be undefined because of the safe navigation operator before it.
Additional information about the issue
Seems related to but still a bit different from this issue: https://github.com/microsoft/TypeScript/issues/53872

When foo is undefined, then the entire right side expression won't be called. That means param.slice() is never evaluated.
Try running your playground. It works just fine, even when foo is undefined.

typescript knows that param could be string or undefined here.

Correction: It knows that the whole expression foo?.param can be string or  undefined.  However, ?. is short-circuiting so if foo is defined, foo.param is always a string, per the types.  If foo is nullish then foo?.param.slice doesn't even get evaluated.

The behavior of ?. is admittedly counterintuitive; the expression a?.b.c is not the same as (a?.b).c
Regardless, TypeScript accurately models the runtime behavior here.

interesting, apologies for mix up. I could have sworn I've run into issues around Cannot read properties of undefined similar to my example, but I can't reproduce it now so it must have been something else!


feat(image): add imgPropsPreview prop.

related to https://github.com/tusen-ai/naive-ui/issues/3515

Codecov Report

Merging #3520 (2e8d1c1) into main (72bd612) will decrease coverage by 0.10%.
The diff coverage is 100.00%.

:exclamation: Current head 2e8d1c1 differs from pull request most recent head 0f71f4d. Consider uploading reports for the commit 0f71f4d to get more accurate results

@@            Coverage Diff             @@
##             main    #3520      +/-   ##
==========================================
- Coverage   63.09%   62.99%   -0.11%
==========================================
  Files        1050     1056       +6
  Lines       21791    21923     +132
  Branches     5666     5719      +53
==========================================
+ Hits        13750    13810      +60
- Misses       6565     6623      +58
- Partials     1476     1490      +14

Impacted Files
Coverage Δ

src/image/src/Image.tsx
75.94% <ø> (ø)

src/image/src/ImagePreview.tsx
31.27% <100.00%> (ø)

src/grid/src/GridItem.tsx
80.00% <0.00%> (-16.00%)
:arrow_down:

src/data-table/src/TableParts/ExpandTrigger.tsx
77.77% <0.00%> (-9.73%)
:arrow_down:

src/transfer/src/use-transfer-data.ts
55.76% <0.00%> (-7.03%)
:arrow_down:

src/list/src/List.tsx
74.19% <0.00%> (-6.58%)
:arrow_down:

src/date-picker/src/panel/panelHeader.tsx
60.86% <0.00%> (-4.14%)
:arrow_down:

src/_internal/select-menu/src/SelectMenu.tsx
60.54% <0.00%> (-4.09%)
:arrow_down:

src/switch/src/Switch.tsx
64.03% <0.00%> (-3.93%)
:arrow_down:

src/upload/src/utils.ts
47.95% <0.00%> (-3.73%)
:arrow_down:

... and 56 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

I think you may need to rebase or cherry-pick your commits to exclude unrelevant commits.

Yeah. Ill recreate it. Initially it started from docs, with adding an example. 😅

https://github.com/tusen-ai/naive-ui/pull/3545


omit empty coupon fields in XML

Recurly only requires coupon_code, name, and discount_type properties when creating a coupon via the API. This PR makes optional arguments optional.
When these were not omitempty, we received errors from Recurly's API (the provided xml was invalid).
Additionally, the boolean arguments defaulted to false when not explicitly set to true, which was a surprise as Recurly assumes some of them default to true (e.g. applies_to_all_plans).
After this change, Recurly accepts the XML payload and implicit defaults are as expected.

@bobholt Thanks for the contribution!


Why does _DataProviderElement not mark the widget as dirty?

After going a bit through the source code of Stacked I found the following difference in the following class between StatelessWidget and ViewModelWidget.
class _DataProviderElement<T> extends ComponentElement {
  ...

  @override
  void update(ViewModelWidget newWidget) {
    super.update(newWidget);
    assert(widget == newWidget);
    rebuild();
  }
}

 class StatelessElement extends ComponentElement {
   ...

  @override
  void update(StatelessWidget newWidget) {
    super.update(newWidget);
    assert(widget == newWidget);
    _dirty = true; <--- this is marked as dirty
    rebuild();
  }
}

I am wondering why this is the case and if it's correct.
Thanks,
Rick

@ricksecretin we don't use that value internally as we only want to build once and then rebuild ourselves using notifyListeners. I also think that at the time of building stacked that value was not being set to _dirty.
Maybe it should be added.

If you can make a PR of this I can keep this issue open. Otherwise I will close it.


how to fix the problem of the position when i type in searchbar for a view on the search

editor.translate_to = function(x, y) {
var pos_x = x * (this.precanvas.clientWidth / (this.precanvas.clientWidth * this.zoom)) - (this.precanvas.getBoundingClientRect().x * (this.precanvas.clientWidth / (this.precanvas.clientWidth * this.zoom)));
var pos_y = y * (this.precanvas.clientHeight / (this.precanvas.clientHeight * this.zoom)) - (this.precanvas.getBoundingClientRect().y * (this.precanvas.clientHeight / (this.precanvas.clientHeight * this.zoom)));
this.canvas_x = pos_x;
this.canvas_y = pos_y;
let storedZoom = this.zoom;
this.zoom = 1;
this.precanvas.style.transform = "translate(" + pos_x + "px, " + pos_y + "px) scale(" + this.zoom + ")";
this.zoom = storedZoom;
this.zoom_last_value = 1;
this.zoom_refresh();
}
var infonode = '';
$("#search").on('keyup', function(e) {
e.preventDefault();
var value = $(this).val().toLowerCase();
$(".drawflow-node").filter(function() {
var isFind = $(this).text().toLowerCase().indexOf(value) > -1;
if (isFind) {
$(this).addClass("isFind");
var idnode = $(this).attr('id').replace('node-', '');
infonode = editor.getNodeFromId(idnode);
} else {
$(this).removeClass("isFind");
}
if (value == '') {
infonode = '';
$(this).removeClass("isFind");
}
});
if (infonode != '') {
console.log('infonode -----');
console.log(infonode.pos_x + ' / ' + infonode.pos_y);
editor.translate_to(infonode.pos_x, infonode.pos_y);
}
});

a problem because the position is not the good when i write in search bar

Can you detail your problem more?
What is that search? Where is?
You are moving the canvas. Where do you want to move it exactly?
Can you provide an example?

The search bar in yellow find and fix the camera on the box but when i write

the box in border red is not finds in the good positions

Have you tried the function here:

https://github.com/jerosoler/Drawflow/issues/88

I see that it is similar but different

for the contested menu

1: I retrieve the x and y positions of the box
2: there is a column on the left
3: so what is the formula with trick 88 to arrive at the result of the capture

Tested on the demo:
editor.translate_to = function(x,y){
	this.canvas_x = x;
	this.canvas_y = y;
	let storedZoom = this.zoom;
	this.zoom = 1;
	this.precanvas.style.transform = "translate("+this.canvas_x+"px, "+this.canvas_y+"px) scale("+this.zoom+")";
	this.zoom = storedZoom;
	this.zoom_last_value = 1;
	this.zoom_refresh();
}

const nodeInfo = editor.getNodeFromId(5);

editor.translate_to(-1*nodeInfo.pos_x,-1*nodeInfo.pos_y);

Works with zoom is 1.


Port compatible ci fix to develop

Port https://github.com/MinaProtocol/mina/pull/16016 to develop

!ci-build-me

!ci-build-me


New update on the new design of YouTube

Hi, it's possible you can update YouTube Center to the new YT design?

this is a duplicate of #2439


Fix up DNS

Figure out some solution to make DNS work well both inside and outside Tailscale

Will be revisited from a k8s-based perspective if needed (see #35)


[Technical] Added interface for the Roslyn analyzer provider

Amended the pre-processor to call the analyzer provider (WIP)

LGTM


[Question] Focusing a TextField

Is there a recommended approach for focusing a TextField (or any material element for that matter)? I would like to focus a TextField on mount, for example. I tried adding a ref to the component and focusing it that way, but the actual <input>or <textarea> is a nested element. Apologies if I missed something in the documentation.

@stevewillard they give className which I am guessing we could use good old vanilla JS:
document.querySelector('.className input').focus()

Ah, good idea. Thanks, I'll try that!
If that works, I might create a wrapper around TextField that takes a focus or autoFocus prop, which would could do this on prop change or mount.

For anyone curious, it turns you you can simply put the prop autoFocus (cased like that) on a TextField, and it just works!
<TextField autofocus />

<TextField autofocus/> doesn't appear to enable the focus visual state though.

It does for me. It's autoFocus with a capital F
I stumbled with that a few times myself...

Yeah, I tried that too. It appears to be due to the tabs/tab hierarchy, since it works for one tab and not the other.
something like:
<Dialog>
  <Tabs>
    <Tab>
      <TextInput autoFocus/>
    </Tab>
    <Tab>
      <TextInput autoFocus/>
    </Tab>
  </Tabs>
</Dialog>

only tested in FF + Chrome and it breaks for one tab in both browsers. Lazy rendering of the tab content fixes the issue. (Also, why isn't the content lazily rendered in the first place?)
Will come up with a repro example later.

I found about autoFocus but found that it only works when the page first loads, not after form submit. The way I finally found it can be done is by adding a ref to the child TextField and the calling select() on the form submit:
<form onSubmit={this.onSubmit}>
            <TextField ref="amountComp" ... />
</form>

and
onSubmit(event: any): void {
    // save form
    (this.refs["amountComp"] as TextField).select();
};


photos of account managers

@jprzybylski4 i need it for the support widget (now we have static - based on settings... new will be dynamic)

Working on it - should have all the photos by Monday

Marta Masternak - https://res.cloudinary.com/ecommerceberlin/image/upload/v1636370755/Awards website/marta.png
Dominik Kleina - https://res.cloudinary.com/ecommerceberlin/image/upload/v1648629512/Exhibitors/expojuicer/Dominik_Kleina.jpg
Gerome Yalim - https://res.cloudinary.com/ecommerceberlin/image/upload/v1648629534/Exhibitors/expojuicer/Gerome_Yalim.jpg


Add to HACS default repo

Task to track getting Bermuda into the HACS default repo

[x] Project structure and manifest
[x] Use releases
[x] Ensure HACS action runs OK
[x] Ensure Hassfest action runs OK
[ ] Get tests working - see #22
[x] Have logo and icon accepted into HA Brands repo - see https://github.com/home-assistant/brands/pull/4772

PR Raised for HACS/Default https://github.com/hacs/default/pull/2443


Message groups to actions

Closed in favour of #158 because GitHub fails to display actual differences after rebasing on newer master.


[FEATURE] : Footer component

New feature for issue https://github.com/yashchaudhari008/minime/issues/7
Contain:

Footer component
Footer scss module designs
Github icon component
Github repository page link
yashchaudhari008 github profile link
Contributors page link

Also please mention yourself on the issue, so that I can assign it to you

While making the changes, I encountered a bug with the font-weight of the Inter font. I was able to resolve it, but I'm unsure whether to include it in this pull request or create a new one.

@linyers What's the exact issue?

The issue was with the Inter font. When attempting to increase the weight of the Inter font, it remained at the default (400). I also noticed that certain components were using a different weight than the default, and the weight stayed at 400 even when set to 800. So, I imported various weights for the Inter font, and the issue was resolved.
in src/index.scss
@import url("https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800;900...");

Can you check whether this happens only when Chrome is opened in incognito mode? Because this is happening in my case!

Also, can you push your recent changes and request re-review?

Can you check whether this happens only when Chrome is opened in incognito mode? Because this is happening in my case!

I have been noticing that this seems to be some issue with browsers. I tested it on Chrome, Brave, and Firefox. I'm sharing some links that discuss this:
https://stackoverflow.com/questions/22001035/font-weight-ignored-in-chrome
https://github.com/tailwindlabs/tailwindcss/issues/1402
I have tried different solutions, and the one that worked for me was importing the weights I am going to use:
@import url("http://fonts.googleapis.com/css?family=Open+Sans:400,300,500,800");


npm build 1.2.1 wrong?

Hi,
When I do npm install -g homebridge-tuya-lan I'm installing the version 1.2.1, but actually the code is outdated. e.g. the SimpleBlindsAccessory is missing.

Same here, it seems that TWLight is not deployed either, I'm using 1.2.1 and have doesn't have a valid type defined message.

Please give the latest rc release a shot by doing npm i -g homebridge-tuya-lan@rc. It includes logic to understand this newer API.
A known issue is that the current state is not reported by some devices; they however work fine as soon as you interact with them. I have reached out to Tuya for a solution.
The Setup Instructions have changed in case you need to obtain a fresh id and key.


How to pass info from SlidMenu to HomeViewController using segue?

I have read the guidelines for contributing and I understand

[ ] My issue is happening in the latest version of SideMenu (older versions are no longer maintained).
[ ] My issue was not solved in the README.
[ ] My issue can not be answered on stackoverflow.com.
[ ] My issue is not a request for new functionality that I am unwilling to build and contribute with a pull request.
[ ] My issue is reproducible in the demo project.

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
I am trying to pass flag from SlidMenu rootViewController to my HomeViewController, don't want to push any ViewController. Here i'm using Storyboard and segue. i tried to check other open/closed issues but couldn't find answer.

If I understand your issue correctly, I did it with a callback. Here is a tutorial video. It is in Russian, but you can check code:
https://www.youtube.com/watch?v=SiMPvYjLlJk

This question is more appropriate for StackOverflow.com.


Add Autoscaling

This PR allows enabling/disabling and customizing autoscaling for model endpoints in sagemaker inference.

/test-e2e-deploy sha=446e3da

It seems like it didn't pass the e2e test with the error:
30
    raise Exception(
31
Exception: Failed to run command aws --region us-west-1 cloudformation deploy --stack-name sagemaker-bento-deploy-test-endpoint --template-file /home/runner/work/aws-sagemaker-deploy/aws-sagemaker-deploy/TestService_20211119212312_12639B_sagemaker_deployable/api_template.json --capabilities CAPABILITY_IAM:
32
Failed to create/update the stack. Run the following command
33
to fetch the list of events leading up to the failure
34
aws cloudformation describe-stack-events --stack-name sagemaker-bento-deploy-test-endpoint```

@NaxAlpha Can you look into it?

cc @jjmachan

Hi, @yubozhao Thanks a lot for the review. I am not sure what caused the test to fail, but in my case, what happened was that sometimes it would fail because of some unknown reason, and if I tried again, it would work. I will try to investigate the issue.

what is the status of this @NaxAlpha ?


Documentation book is not searchable

Search results on https://rust-driver.docs.scylladb.com/stable/index.html don't include docs for rust driver.
For example searching for Default Retry Policy gives some results, but none of them are from rust driver book: https://rust-driver.docs.scylladb.com/stable/index.html#q=default retry policy
Broken search severely limits usability of these docs.
When viewing search results on the left there are a few project listed, but rust driver isn't there, maybe it needs to be added?
Search used to work well in the old mdbook book: https://rust-driver.docs.scylladb.com/stable/index.html#q=default retry policy

you reposted the official docs link again instead of the old book - but, in any case, I think it's an issue that should be reported to scylladb/scylladb, because it's the official documentation that's broken

Oops fixed the link.
Ok, I will open an issue in scylladb/scylladb

oh wait - I just noticed we generate these sphinx docs in this repo. So no need to open an issue in scylladb/scylladb

@psarna You generate the documentation in this repo, but I must be aware of any problems with the docs, so thanks @cvybhu for letting me know :)
I'm not yet sure if the problem is on our end or if it's the search that's causing it. The search mechanism is provided externally, so I've opened a ticket with the provided.

The problem was caused by our search configuration. It has now been fixed. Here is a screenshot I've just taken, but you can verify yourself by searching for another Rust driver-related phrase.

PS. The name of the product on the selection menu will be updated later to ScyllaDB Rust Driver.

Awesome thanks, closing as fixed


Extensions in devcontainer.json get installed in the wrong host on codespaces

Does this issue occur when all extensions are disabled?: No

VS Code Version: 1.69.0 (codespaces)
OS Version: MacOS 12.4 (chrome)

Steps to Reproduce:

Use/identify an extension which can run in different extension hosts depending on host availability following the pattern agreed in https://github.com/microsoft/vscode/issues/141322 (e.g. arm.device-manager)
Create a GitHub repository containing a devcontainer.json file with this extension (e.g. this one)
Create a codespace on that repository and observe all extensions are installed in the remote host as codespace extensions

Expected behaviour - the multi-host extension should install as a web extension into browser extensions.
When installing this extension manually, it behaves correctly:

This is designed by the codespaces to read the devcontainer.json on server side and  install extensions there. Please file the issue against the codespaces if you think otherwise.

@sandy081 Where is the repo/issues for codespaces, please?

Here it is https://support.github.com/features/codespaces

Moved to: https://github.com/orgs/community/discussions/41636


use RequestBody for attachment content

This PR let's people use a RequestBody instead of Lazy Bytestring to create an attachment. This gives people more fine grained control on how the content of the attachment is loaded. For example, in my use case, I had to load a file from Amazon S3, and upload it as an attachment. However due to the memory limit of the VM I'm running the bot on, it would crash due to OOM if I try to upload a huge file. Fiddling with Lazy Bytestring wasn't yielding any good results so I came up with this PR.
With this PR, I can upload a body :: ConduitM () ByteString (ResourceT IO) () with requestBodySourceChunked from http-conduit, without running into memory problems.
let file = CreateMessageAttachment filename Nothing $ requestBodySourceChunked body
followUp (intoMsg ([i|<@#{showID $ user ^. #id}>|] :: Text) <> intoMsg file)

Nice, thanks :)


Runtime Error

Hello, I did not change any code, but after running it, I encountered this error message. I don't know how to resolve it.

Looking forward to your reply, thanks!

And I failed to run download_fg_masks.sh to download the foreground masks. Is this file necessary to download?  ❀

What error are you getting when you run download_fg_masks.sh?

What error are you getting when you run download_fg_masks.sh?

It turns out that the download failed due to network problems. After the file is downloaded, the error no longer exists. Thanks!