Remove the unnecessary QuestionnaireItemWithResponse class

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Description
Remove the unnecessary QuestionnaireItemWithResponse class
Alternative(s) considered
Keeping this class around adds nothing to the code
Type
Choose one: Code health
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct
[x] I have read How to Contribute
[x] I have read the Developer's guide
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally
[x] I have built and run the reference app(s) to verify my change fixes the issue and/or does not break the reference app(s)

Codecov Report

Merging #780 (c175752) into master (6c866af) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #780      +/-   ##
============================================
- Coverage     53.06%   52.96%   -0.10%
+ Complexity      198      197       -1
============================================
  Files            48       48
  Lines          1027     1027
  Branches        146      146
============================================
- Hits            545      544       -1
  Misses          396      396
- Partials         86       87       +1

Impacted Files
Coverage Δ

.../google/android/fhir/db/impl/dao/LocalChangeDao.kt
66.66% <0.00%> (-2.09%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6c866af...c175752. Read the comment docs.


Component Doc Usability Testing

Usability tests to quantify improvements with the new component docs versus the old ones.
Key Metrics

Efficiency - as measured by time on task
Discoverability - as measured by error rate
Satisfaction
Usability, Trust, Appearance, Loyalty - SUPR_Q

### Tasks
- [x] Plan out usability test
- [x] Identify participants - going to recruit external audience via UZ
- [x] Schedule test
- [x] Complete test
- [ ] Report results

Sep-8: Brief drafted; in review with leads.

Sep-15: Programming test in UZ; will look to run this weekend / early next week

Sep-22: Test is live, being closed today. Will conduct analysis.


Feedback: More examples

For ApplyProductPartitionActions Service Operation - Campaign Management, and other pages, I feel like there need to be more examples. For example, with ApplyProductPartitionActions, there is an add, update, and delete action. The bullet-points cover them briefly, but in my opinion, there should be unique examples of the Request for each action, making figuring out what I need to supply much easier.

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

ID: b32ed26c-9984-a943-7bfd-b40de2175967
Version Independent ID: 86531dd9-a58a-d3dd-de9e-260935155052
Content: ApplyProductPartitionActions Service Operation - Campaign Management - Microsoft Advertising
Content Source: Advertising/bingads-13/campaign-management-service/applyproductpartitionactions.md
Service: bing-ads-campaign-management-service
GitHub Login: @eric-urban
Microsoft Alias: eur

@Ed-Ed please note there are Add and Update examples here. Does this help?

Sorry I should have been more clear in the feedback. I was specifically referring to the XML. I have seen the C# examples, but there's not really helpful.
This isn't an issue I'm having anymore, just a suggestion.

@Ed-Ed thanks for clarifying! The xml template is generated by a tool to show the order of the body and header elements for the SOAP request. For supported types that you can use with this service operation, we refer readers to the reference details above on the same page.


Bookmark Usage Reporting

Will Bookmarks receive the same reporting that SharePoint Online Query Rules/Promoted Results currently benefit from?

Providing more insight into how bookmarks are functioning is something we'd like to do, but we do not have any dates to share at this time.


Mixed type project (webpack and rust) is missing template and documentation

I have a mixed project using webpack and a rust package compiled beforehand with wasm-bindgen. Everything is handled by a bash script, and I wondered whether I could simplify this workflow by using wrangler.
I tried using the rust template, edited wrangler.toml to set type = "webpack" and tried importing a random package, but the preview yields wasm_bindgen is not defined as an error. Is this process supported? or is it too early for now?

Have you tried using https://github.com/wasm-tool/wasm-pack-plugin? You should be able to import the wasm module via webpack.

I've been trying a few things, for example, copying https://github.com/xtuc/wrangler-js-demo/tree/master/rust (which uses wasm-pack-plugin) and running wrangler preview get in the directory gives me this error 👷♀ Your worker responded with: ReferenceError: wasmprogram is not defined.
The created wasm module is named module.wasm in the worker directory, but the metadata.json references a different file:
                {
                    "body_part": "script",
                    "binding": {
                        "name": "wasmprogram",
                        "type": "wasm_module",
                        "part": "wasmprogram"
                    }
                }

Is there any barebone template that I can use?

Right now a few things are broken in the latest released version of wrangler (namely, the binding upload format) for this to work. These issues should be fixed soon! However, I will give instructions to get this working today, as well as instructions to go back to the next stable release of wrangler when it comes out.

git clone the master branch of wrangler.
run cargo uninstall wrangler to get rid of the current released version of wrangler.
run cargo install --path . from inside the wrangler directory you cloned, this will install the master version of wrangler that fixes the binding format
however, wrangler still pulls in some dependencies when installed this way, and we need to update one of them manually (wranglerjs, the glue layer used to call webpack) as the released one is incompatible with the master branch
go to the cache directory on your machine, where a .wrangler directory will be located.
inside .wrangler replace index.js with the latest version from the current master version of wrangler using rm index.js && wget https://raw.githubusercontent.com/cloudflare/wrangler/master/wranglerjs/index.js

Now you're on the latest wrangler. In your project you need to replace the contents of worker/metadata.json with
{
    "body_part": "script",
    "bindings": [
        {
            "name": "wasmprogram",
            "type": "wasm_module",
            "part": "wasmprogram"
        }
    ]
}

add to your webpack.config.js the following settings. You'll need to add wasm-pack-plugin to your package.json as a devDependency.
const WasmPackPlugin = require("@wasm-tool/wasm-pack-plugin");

module.exports = {
  entry: {
    index: <wherever the entry point javascript file for your worker is>
  },
  plugins: [
    new WasmPackPlugin({
      crateDirectory: __dirname,
      extraArgs: "--out-name index"
    }),
  ]
};

Finally, in the JS portion of your app, use let wasm = await import('<relative path to the pkg directory from that file>'. wasm will be an object that contains the functions you exported using wasm-bindgen, you can look inside pkg/index.js to see how it's created after running wrangler build
When a new version of wrangler is released that fixes rust+webpack projects, you'll have to run cargo uninstall wrangler and delete the .wrangler directory in the cache dir (only to go back to stable, NOT for normal upgrades).

Some of this work should be made easier by the work we are doing to fix bindings in general.

removing this from the Refactor Bindings, Bundling milestone, as what we really need is a webpack config template for this.

Though @xortive provided a workaround at this moment, I spend few hours and still couldn't get it working.
From the README, is describes:

webpack: This project contains any number of JavaScript files or Rust/C/C++ files that compile to WebAssembly. Rust files will be built with wasm-pack. This project type uses webpack and webpack plugins in the background to build your worker.

Just wanna make sure that wasm-pack-plugin is still required?

@dlackty yes, wasm-pack-plugin is still required to call wasm-pack when using the webpack project. The README is inaccurate here, I'll update this issue to reflect that

i think we keep missing this issue because it's filed here and not on the docs repo. now that that repo is open source, i'm going to move this to that repo!


Change the default prompt color from green to lime

Closes #427

Apparently this gives a warning, the second time you run it:
LIMA| WARNING: Failed to execute /mnt/lima-cidata/boot/08-shell-prompt.sh

patching file .bashrc
Reversed (or previously applied) patch detected!  Skipping patch.
2 out of 2 hunks ignored

Should probably leave some kind of text that could be grepped ?

Thanks, but this doen't seem to work with the default configuration of tmux (version 3.2a)?
(Adding set-option -g default-terminal "screen-256color" to ~/.tmux.conf worked for me)

Hmm, it shouldn't be any different from the previous (ubuntu) setup ? What is the tmux invocation for lima ?

Maybe, just PS1="[LIMA] $PS1" might be fine

And for UTF-8 it would be 🄻🄸🄼🄰 or something

Then again, that will break a dozen other scenarios - and doesn't even seem to work on GNOME Terminal


✨  small error improvements

no issue

in Ignition we have added keeping the original stack, i copied it over
i would like to use Ignition in Ghost asap to avoid having inconsistencies
added support for options.err is a string

ready for review


2 subcharts with different versions results in one not being rendered during dry-run/install

Output of helm version:
Client: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.2", GitCommit:"a80231648a1473929271764b920a8e346f6de844", GitTreeState:"clean"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:21:50Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"f588569ed1bd4a6c986205dd0d7b04da4ab1a3b6", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
AWS
I have a Chart with a requirements.yaml that looks like the following:
dependencies:
  - name: chartA
    repository: "LOCAL-REPO"
    version: 1.0.0
  - name: chartB
    repository: "LOCAL-REPO"
    version: 2.0.0
    alias: "friendlyNameB"
  - name: chartB
    repository: "LOCAL-REPO"
    version: 1.0.0
    alias: "friendlyNameC"

I deploy chartB twice with different override configurations and also different versions of chartB.
In the output of my dry-run only one of the chartB templates get rendered. When they both use the same version then all templates render as expected. Is it expected to use the same version of subcharts of the same origin?

I'm seeing similar behavior but sounds like it's under different conditions. In my case I'm trying to deploy different aliases of the same version of a chart (with different values) and it still only deploys one set. I tried deploying different versions and I'm still seeing the same issue.
In my case, it looks like helm dep up just ignores the alias field, or at least it doesn't save it in requirements.lock and under charts/ I only see one chart, as opposed to one chart per alias, as implied by this statement in the documentation: "The manual way of achieving this is by copy/pasting the same chart in the charts/ directory multiple times with different names." (https://docs.helm.sh/developing_charts/#alias-field-in-requirements-yaml). Is this happening in your case too?

Hi @tldoty This is probably "undefined behavior" but I suspect that 'alias' implies same chart and same version. As @patoarvizu points out, the docs essentially say "copy/pasting the same chart".
@patoarvizu IIRC you are correct and helm dep is not alias aware. You should manually control the aliased charts on disk.

@jascott1 Wait, I don't get it. Then what's the point of having aliases if I'll have to manually control the versions? Are you saying that alias is just the mechanism to have multiple versions of the same chart? That would seem to contradict the example given here: https://docs.helm.sh/developing_charts/#alias-field-in-requirements-yaml

@patoarvizu Alias was designed for multiple installs of the same chart (including the version). Sorry for the delay in reply. Did you find a suitable solution?

We believe this is an issue with the version of Helm we're currently using (2.6.1). The original problem was addressed with a different approach, although we ran into it again later for a different problem and we ended up doing some stitching together of things via pure gomplate and bash. Basically a very raw version of kustomize.
If there are no plans to patch 2.6 (or if this is not believed to be an issue), this ticket can be closed.

7 releases have passed since we released 2.6, so we are definitely not planning on patching 2.6. Closing!

This is still a bug in helm package ... or in Helm documentation.
It is being also reported in #9849


Sketching new API: FLoops.@combine

It is sometimes useful to separately define reduction inside of basecase and reduction across basecases. A typical example is histogram computation. Currently, implementing this requires coming up with a gadget like OneHotVector:
@floop ex for i in indices
    @reduce h .+= OneHotVector(i => 1, n)
end

h :: Vector{Int}  # computed histogram

But, if we don't have OneHotVector, it's tricky for users to define this.  It may be a good idea to support more verbose but controllable syntax.
New syntax
The idea is to add a new syntax, for example:
@floop begin
    @init buf = zeros(Int, 10)  # per basecase initialization
    for x in xs
        bin = max(1, min(10, floor(Int, x)))
        buf[bin] += 1  # reduction within basecase (no syntax)
    end
    @combine h .+= buf  # reduction across basecases
end

h :: Vector{Int}  # computed histogram

The new macro @combine takes the same expressions as @reduce does. However, it is not executed inside of the loop body like @reduce.
This is lowered to something equivalent to
function op!!((_, h), (is_basecase, x))
    if is_basecase
        # The left argument is the `buf` inside of basecase:
        buf = h

        # Fused loop body:
        bin = max(1, min(10, floor(Int, x)))
        buf[bin] += 1
    else
        # The right argument is the `buf` when combining sub-solutions:
        buf = x

        # `@combine` instructions:
        h .+= buf
    end
    return (false, h)
end

init() = (false, zeros(Int, 10))

Folds.reduce(op!!, ((true, x) for x in xs); init = OnInit(init))

(with a extra care so that the compiler can eliminate the branch in op! and the base case is compiled down to a straight loop)
The name @combine reflects the Transducers API Transducers.combine.
Comparison
Example: collatz_histogram
https://juliafolds.github.io/data-parallelism/tutorials/quick-introduction/#practical_example_histogram_of_stopping_time_of_collatz_function is an example of using FLoops.jl to compute histogram when you don't know the upper bound:
using FLoops
using MicroCollections: SingletonDict

maxkey(xs::AbstractVector) = lastindex(xs)
maxkey(xs::SingletonDict) = first(keys(xs))

function collatz_histogram(xs, executor = ThreadedEx())
    @floop executor for x in xs
        n = collatz_stopping_time(x)
        n > 0 || continue
        obs = SingletonDict(n => 1)
        @reduce() do (hist = Int[]; obs)
            l = length(hist)
            m = maxkey(obs)  # obs is a Vector or SingletonDict
            if l < m
                # Stretch `hist` so that the merged result fits in it.
                resize!(hist, m)
                fill!(view(hist, l+1:m), 0)
            end
            # Merge `obs` into `hist`:
            for (k, v) in pairs(obs)
                @inbounds hist[k] += v
            end
        end
    end
    return hist
end

This can be written as
using FLoops

function collatz_histogram(xs, executor = ThreadedEx())
    @floop executor begin
        @init buf = Int[]

        for x in xs
            n = collatz_stopping_time(x)
            n > 0 || continue

            l = length(buf)
            if l < n
                resize!(buf, n)
                fill!(view(buf, l+1:n), 0)
            end
            @inbounds buf[k] += 1
        end

        @combine() do (hist; buf)
            l = length(hist)
            n = length(buf)
            if n > l
                resize(hist, n)
                fill!(view(hist, l+1:n), 0)
            end
            @views hist[1:n] .+= buf
        end
    end
    return hist
end

Compared to @reduce version, @combine version has more repetition (for resize!).  However, it can be written without coming up with the abstraction like maxkey and also without knowing SingletonDict.
Example: using mul!
https://juliafolds.github.io/data-parallelism/tutorials/mutations/#advanced_fusing_multiplication_and_addition_in_base_cases shows how to use 5-arg mul!
using FLoops
using LinearAlgebra: mul!

@floop for (A, B) in zip(As, Bs)
    C = (A, B)
    @reduce() do (S = zero(A); C)
        if C isa Tuple  # base case
            mul!(S, C[1], C[2], 1, 1)
        else            # combining base cases
            S .+= C
        end
    end
end

This can be written as
using FLoops
using LinearAlgebra: mul!

@floop begin
    @init C = zero(As[1])

    for (A, B) in zip(As, Bs)
        mul!(C, A, B, 1, 1)
    end

    @combine S .+= C
end

This is much cleaner to use @combine than @reduce.
Discussion/feedbacks

https://julialang.zulipchat.com/#narrow/stream/301865-juliafolds/topic/RFC.3A.20.20new.20reduction.20syntax.60FLoops.2E.40combine.60/near/269832004
https://julialang.zulipchat.com/#narrow/stream/301865-juliafolds/topic/Poll.3A.20.20new.20reduction.20syntax.60FLoops.2E.40combine.60/near/269893356
https://julialang.slack.com/archives/C6SMTHQ3T/p1643424334330809
https://discourse.julialang.org/t/more-threads-slower-code-even-if-not-spawning-them/75242/19

Two variants are discussed in https://julialang.zulipchat.com/#narrow/stream/301865-juliafolds/topic/Poll.3A.20.20new.20reduction.20syntax.60FLoops.2E.40combine.60/near/269893356
(1) @init sub_acc = ... and @combine acc .+= sub_acc (i.e., syntax as in the OP)
@floop begin
    @init subsum = 0.0
    @init buf = zeros(Int, 10)
    for x in xs
        bin = max(1, min(10, floor(Int, x)))
        buf[bin] += 1
        subsum += sin(x)
    end
    @combine s = s + subsum  # equivalent to: @combine s += subsum
    @combine h .+= buf
end

s :: Float64      # computed sum (assuming `subsum::Float64`)
h :: Vector{Int}  # computed histogram
!@isdefined(buf)  # `buf` not defined here
!@isdefined(subsum)  # `subsum` not defined here

(2) @init acc = ... and @combine acc .+= _
@floop begin
    @init s = 0.0
    @init h = zeros(Int, 10)
    for x in xs
        bin = max(1, min(10, floor(Int, x)))
        h[bin] += 1
        s += sin(x)
    end
    @combine s = s + _  # equivalent to: @combine s += _
    @combine h .+= _
end

s :: Float64      # computed sum (assuming `s::Float64` in the for loop)
h :: Vector{Int}  # computed histogram

i.e., @combine acc .+= _ uses _ as an implicit argument for "another acc" from a different task

Some syntax ideas from brainstorming in JuliaLab meeting:
Example 1: maybe useful to "flip" the arguments?
julia> @floop begin
           @init odds = Int[]
           @init evens = Int[]
           for x in 1:5
               if isodd(x)
                   # push!(odds, x)
                   pushfirst!(odds, x)
               else
                   push!(evens, x)
               end
           end
           # @combine odds = append!(_, _)
           @combine odds = append!(_2, _1)
           @combine evens = append!(_, _)
       end
       (odds, evens)
([5, 3, 1], [2, 4])

Example 2:
@floop begin
    @init buf = zero(MVector{10,Int32})
    for char in pidigits
        n = char - '0'
        buf[n+1] += 1
    end
    hist = SVector(buf)
    @combine hist .+= _
end

maybe @combine on rhs?
hist = @combine _ .+= _
hist = @combine _1 .+= _2

use _ as the accumulator?
lhist = SVector(buf)
hist = @combine _ .+= lhist


AssertionFailed in std::sync::once when starting app on release

Bevy version
0.14
Relevant system information
Cargo version: cargo 1.79.0 (ffa9cf99a 2024-06-03)
OS: Windows 11 (build 22631.3810)
Adapter info:
AdapterInfo { name: "NVIDIA GeForce RTX 4060 Laptop GPU", vendor: 4318, device: 10400, device_type: DiscreteGpu, driver: "NVIDIA", driver_info: "555.99", backend: Vulkan }

What you did
I cloned the bevy template  given for the jam (https://github.com/TheBevyFlock/bevy-template)
After cloning it, I simply ran it on release mode
What went wrong
I got the following output:
thread 'main' panicked at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\std\src\sync\once.rs:208:20:
assertion failed: state_and_queue.addr() & STATE_MASK == RUNNING
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\release\bevy_template.exe` (exit code: 101)

Additional information
The error occurs only on release, it doesn't trigger on debug

Backtrace:
thread 'main' panicked at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081\library\std\src\sync\once.rs:208:20:
assertion failed: state_and_queue.addr() & STATE_MASK == RUNNING
stack backtrace:
   0:     0x7ffa14a43c48 - std::backtrace_rs::backtrace::dbghelp64::trace
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\..\..\backtrace\src\backtrace\dbghelp64.rs:91
   1:     0x7ffa14a43c48 - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ffa14a43c48 - std::sys_common::backtrace::_print_fmt
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\sys_common\backtrace.rs:68
   3:     0x7ffa14a43c48 - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\sys_common\backtrace.rs:44
   4:     0x7ffa14a74f09 - core::fmt::rt::Argument::fmt
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\fmt\rt.rs:165
   5:     0x7ffa14a74f09 - core::fmt::write
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\fmt\mod.rs:1157
   6:     0x7ffa14a3a3e1 - std::io::Write::write_fmt<std::sys::pal::windows::stdio::Stderr>
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\io\mod.rs:1832
   7:     0x7ffa14a43a26 - std::sys_common::backtrace::print
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\sys_common\backtrace.rs:34
   8:     0x7ffa14a46b88 - std::panicking::default_hook::closure$1
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:271
   9:     0x7ffa14a467f7 - std::panicking::default_hook
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:298
  10:     0x7ffa14a47188 - std::panicking::rust_panic_with_hook
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:795
  11:     0x7ffa14a47009 - std::panicking::begin_panic_handler::closure$0
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:656
  12:     0x7ffa14a445bf - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\sys_common\backtrace.rs:171
  13:     0x7ffa14a46cf8 - std::panicking::begin_panic_handler
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\panicking.rs:652
  14:     0x7ffa14a9d7d4 - core::panicking::panic_fmt
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:72
  15:     0x7ffa14a9d89d - core::panicking::panic
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\core\src\panicking.rs:146
  16:     0x7ffa14a9c9b0 - std::sys::sync::once::queue::Once::call
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\sys\sync\once\queue.rs:190
  17:     0x7ff65781db5c - _guard_xfg_dispatch_icall_nop
  18:     0x7ff65781009f - __ImageBase
  19:     0x7ff65780cfc5 - __ImageBase
  20:     0x7ff6577de0ba - __ImageBase
  21:     0x7ff9afbd3e93 - bevy_app::app::App::add_boxed_plugin::hdf22ae67fccd9396
  22:     0x7ff6577d8b1c - __ImageBase
  23:     0x7ff9afbd3e93 - bevy_app::app::App::add_boxed_plugin::hdf22ae67fccd9396
  24:     0x7ff65781b226 - <bevy_template::GamePlugin as bevy_app::plugin::Plugin>::build::h998de65a376608c8
  25:     0x7ff9afbd3e93 - bevy_app::app::App::add_boxed_plugin::hdf22ae67fccd9396
  26:     0x7ff65781c66d - <bevy_template::GamePlugin as bevy_app::plugin::Plugin>::build::h998de65a376608c8
  27:     0x7ff65781b5f6 - <bevy_template::GamePlugin as bevy_app::plugin::Plugin>::build::h998de65a376608c8
  28:     0x7ff65781b60c - <bevy_template::GamePlugin as bevy_app::plugin::Plugin>::build::h998de65a376608c8
  29:     0x7ffa14a2bb9e - std::rt::lang_start_internal
                               at /rustc/129f3b9964af4d4a709d1383930ade12dfe7c081/library\std\src\rt.rs:141
  30:     0x7ff65781c9ec - main
  31:     0x7ff65781d1ac - invoke_main
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  32:     0x7ff65781d1ac - __scrt_common_main_seh
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  33:     0x7ffa631c257d - BaseThreadInitThunk
  34:     0x7ffa6432af28 - RtlUserThreadStart
error: process didn't exit successfully: `target\release\bevy_template.exe` (exit code: 101)

21:     0x7ff9afbd3e93 - bevy_app::app::App::add_boxed_plugin::hdf22ae67fccd9396

This is the most interesting line in the backtrace for me. I have no idea what's going on here though: Once should generally not be panicking unless something really weird is going on, and release-mode only is particularly bizarre.

Updating the code fixed it (by simply getting the last commits), but it wasn't a regular build issue like needing to do cargo clean. Not sure what caused the original problem.


merkle: expand test coverage

This PR expands test coverage in merkle to about 80%.  Still need to add coverage relating to RevertBlock but that should probably bring it around 90.

Added RevertBlock support to the tests but it doesn't seem to be working in either case despite updating the proofs.  In the history accumulator test I revert blocks off the top which seems like the logical thing to do and in the regular accumulator I just revert the updated leaves.

ok, I got TestApplyBlock working. It turned out to be quite a bit hairier than I expected, mostly because ApplyBlock modifies both acc and updated. This is annoying. But the alternative (allocating + returning new values) is annoying too, for different reasons. :/
Anyway, it's working now; just a bit more coverage to go. I think we can hit the tricky sections by calling ApplyBlock with added leaves multiple times.

Alright, I think this should be good.

OK I think this should be ready to merge now.


java.lang.VerifyError: Bad return type with 4.2.0 SQLInsertClause

If we call the constructor of SQLInsertClause, we get the following error:
Exception in thread "main" java.lang.VerifyError: Bad return type
Exception Details:
  Location:
    com/querydsl/sql/dml/AbstractSQLInsertClause.values([Ljava/lang/Object;)Lcom/querydsl/sql/dml/SQLInsertClause; @5: areturn
  Reason:
    Type 'com/querydsl/sql/dml/AbstractSQLInsertClause' (current frame, stack[0]) is not assignable to 'com/querydsl/sql/dml/SQLInsertClause' (from method signature)
  Current Frame:
    bci: @5
    flags: { }
    locals: { 'com/querydsl/sql/dml/AbstractSQLInsertClause', '[Ljava/lang/Object;' }
    stack: { 'com/querydsl/sql/dml/AbstractSQLInsertClause' }
  Bytecode:
    0x0000000: 2a2b b602 74b0

Duplicate of #2275, but thanks so much for reporting.
😅


Fix human_readable_quest for v2

fixing human_readable_quest function which doesn't take into account differences between v1 (where mining and gardening are still running) and v2 quests (everything else) and thus provides wrong results when querying v2 quests because the positioning of startBlock and startTime has been swapped in v2. This change will be obsolete once mining and gardening are moved to v2 quests

Implemented in cf50b25
I could not merge easily since I have change whole structure of the project


I can't close the panel?

I go to "Packages>Regex Tester>Toggle" but this just highlights the "Regular Expression" input field of the panel instead of closing it when it's open.
Can you add an 'x' (close) button to the panel?

This should be solved in 0.2.2: There is a Hide command, and the Esc key would do the same.

There is still no close button though. The next step is refactoring the UI.


nuxt page routes are not getting rendered, instead express api takes over the routing

i am new to nuxt. I started a project using create-nuxt-app and i selected express as my server. I created a sample api using the express that create-nuxt-app generated for me. Unfortunately, anytime I run my application and visit the routes, the nuxt pages do not get involved. All i get is a json response from my express api. Please help.

Do you use  OR a standard Link Text tag?

i used

I used <nuxt-link to="/my/route" />

See also a somewhat similar issue #220.


Make filepath optional

And delete https://github.com/noraworld/issue-recorder/tree/cb7383bc4e518bb8d45e925f787da577a8ddb522#:~:text=Please note that you have to specify the filepath at the moment. This will be optional in the future. Stay tuned.


[mle-router] fix uninitialized message in SendChildUpdateRequest()

Fixes the following issue introduced in #7481:
../openthread/src/core/thread/mle_router.cpp:3163:26: note: ‘message’ was declared here
     Message *            message;
                          ^~~~~~~

I think this is not actually a bug because the uninitialized message will never be used. Thought? @jwhui @abtink

Yeah, I think that's right. In the case where we call ExitNow(), error should be kErrorNone.

I think this is not actually a bug because the uninitialized message will never be used. Thought? @jwhui @abtink

Yeah, I think that's right. In the case where we call ExitNow(), error should be kErrorNone.

should we remove label: bug if it's not a bug ?

should we remove label: bug if it's not a bug ?

Good question. It does cause build errors for some platforms depending on tool chain, blocking some of the dependabot PRs. Do we consider that a bug?

Good question. It does cause build errors for some platforms depending on tool chain, blocking some of the dependabot PRs. Do we consider that a bug?


Update azure-services-in-fedramp-auditscope.md with Azure Open AI

Azure Government now has Authorization for Fed Ramp High and IL2.   You can validate via https://marketplace.fedramp.gov/products/F1603087869

@Jain-Garima
Can you review the proposed changes?
Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@Jain-Garima
Can you review this old PR and determine whether it needs to be closed or merged?
@MicrosoftDocs/public-repo-pr-review-team

@rohrerb
The article has been updated to reflect this change. If you'd still like to update the article, please open a new PR. Or if you believe this PR was closed by mistake, email the PublicPRs alias.
#please-close


Issue checking Convergence.thy in Isabelle2018

I am trying to check the proof in src/supplemental using Isabelle2018.
Isabelle is failing (for the first time I think) on the following line in Convergence.thy:
definition apply_operations :: "'a list ⇒ 'b ⇀ 'b" where
  "apply_operations es ≡ foldl (op ⊳) Some (map interp es)"

Here's how it appears to me:

As an Isabelle noob, it is likely an issue with my setup. Any suggestions?

Replacement by kleisli seem to fix the problem

Yes, that has fixed it for me. Thanks!


Reenable skipped tests for netlify dev and middleware work

Some tests were skipped as they only ran locally but not in CI. Investigate why the skipped tests weren't able to run successfully in CI/CD.
See https://github.com/netlify/next-runtime/pull/1831

https://github.com/netlify/next-runtime/issues/1953 - closing this issue, but ensure this work is done in this ticket

Hey @nickytonline!
Closing this as we've got better test coverage on the v5 runtime now. 💪🏻
The v4 runtime is now in the maintenance support phase, with no new features being added. Occasional bug fixes and security patches will be applied when needed.
Thanks!


docker container for python-rtmbot?

Is there a minimal docker container available for python-rtmbot, which would simply require a user to pop some bot scripts into a specified location in order to construct an easy to deploy image containing them?

We have a fork of python-rtmbot with our own bot, but maybe you can just use our Dockerfile to build your own image: https://github.com/cloudwalkio/python-rtmbot/blob/master/Dockerfile

Anything stopping that fork from being PRed into the main repo?

For those curious, I do this with Netflix/hubcommander:
https://github.com/Netflix/hubcommander/blob/develop/build_docker.sh
and
https://github.com/Netflix/hubcommander/blob/develop/Dockerfile


feat(ingestion): schema, table filtering for redshift-usage

Filter redshift usage statistics based on schema and table patterns.
Checklist

[x] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[x] Links to related issues (if applicable)
[x] Tests for the changes have been added/updated (if applicable)
[x] Docs related to the changes have been added/updated (if applicable)

Trying to implement this feature request:
https://feature-requests.datahubproject.io/b/feedback/p/redshift-usage-support-table-and-schema-filtering

@Abhiram98, looks great overall! It would be great if you could address the comments above.


Test Issue

I do not see any documentation on the Cloud Partner Portal.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
ID: 6cb76940-1c5d-b616-880a-deffdcda5d1b
Version Independent ID: 78c318f9-697f-ca24-ca1a-9c36b7abe9f3
Content: Non-technical prerequisites for creating an offer for the Azure Marketplace
Content Source: articles/marketplace-publishing/marketplace-publishing-pre-requisites.md
Service: marketplace
GitHub Login: @msmbaldwin
Microsoft Alias: mbaldwin

@seshenoy We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


chore: Migrate datastore synth.py to bazel

The code was regenerated, there were no changes (except synth.metadata, which we agree to not include in these PRs)

@chingor13 PTAL


cyclone-scheme: 0.21 -> 0.30.0

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 130628 run on x86_64-linux 1

1 package built:

cyclone-scheme

Result of nixpkgs-review pr 130628 run on x86_64-darwin 1

1 package built:

cyclone-scheme


Subaru: show LDW on dash for correct lane

Wire up the left and right lane departures to the correct
Subaru messages
This goes with https://github.com/commaai/cereal/pull/147 - and needs much more work to make the new messages work across all cars - sending this over as a draft to get some feedback on the approach.

Why do you need to create new alerts for this? Toyota already does this using the values from hudcontrol:
See:

https://github.com/commaai/openpilot/blob/master/selfdrive/controls/controlsd.py#L483-L484
https://github.com/commaai/openpilot/blob/master/selfdrive/car/toyota/interface.py#L386-L390
https://github.com/commaai/openpilot/blob/master/selfdrive/car/toyota/carcontroller.py#L143

On the subaru, we can only show one alert on the dash to the user at a time (keep hands on wheel, left lane departure, right lane departure), It seemed to me that the Events model inside OP was the best place to determine what should be shown as opposed to trying to guess in the car implementation.
E.g. what should the car show if a lane is being departed, but OP has some other higher priority alert to display (e.g. FCW).  By using the VisualAlert value we leave OP fully in control of what is shown to the user

There's no guessing needed in the car controller. If you get a VisualAlert.ldw in the car controller, use CC.hudControl to determine the lane.

Ahh right, that will work, thanks - note that I will still need to alter EventName.ldw to emit the VisualAlert.ldw and adjust all car implementations to understand VisualAlert.ldw (to do the same as VisualAlert.steerRequired) - will that work for you?

That should be fine.

Any update on this? Otherwise, will close due to inactiviy.

Yeah, sorry - it took a while to fully test the changes on the road.  I've updated the patch now.


Add auto update logs

When a request to a domain occurs, it is necessary to refresh the logs page to see it. I suggest to add auto refresh of logs (for example, once in N time)

Added on v2.19.0-beta.1.


grunt-util deprecation warning in yarn upgrade due to gulp-decompress

Seeing this deprecation warning about grunt-util when upgrading a yarn/npm package. This is due to  gulp-decompress
warning grunt-contrib-imagemin > imagemin-optipng > optipng-bin > bin-build > download > gulp-decompress ><EMAIL_ADDRESS>gulp-util is deprecated - replace it, following the guidelines at https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5

Related to the issue from gulp-decompress: https://github.com/kevva/gulp-decompress/issues/19

Sorry, didn't realize an issue was made for this already: https://github.com/gruntjs/grunt-contrib-imagemin/issues/387
Closed this to avoid confusion


Update testdata locations with xclim-testdata source

Pull Request Checklist:

[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes issue #xyz

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Documentation has been added / updated (for bug fixes / features)
[ ] HISTORY.rst has been updated (with summary of main changes)
[ ] I have added my relevant user information to AUTHORS.md

What kind of change does this PR introduce?:

All this PR does is update the testdata and notebook locations for the HadGEM CMIP5 data presently in a PR here: https://github.com/Ouranosinc/xclim-testdata/pull/7. Once that PR is merged and the branched is closed, the get_file calls won't need to specify a specific branch.

Does this PR introduce a breaking change?:

Nope.

Other information:

Once this is merged, I can safely delete the now-merged branch.

@Zeitsperre looks good.


add pages dicky.html

Your pull request needs further work because of the following reason(s):

More than one file has been added/removed/modified.

Once you have resolved the issues, comment on this request to be re-judged
This is an automated response, beep boop.
if you think there is a mistake, contact a maintainer

39a8051b28903e3845a1d129854209a63f55302d

None of this is right. None of it.


please put the mappings on the README.md

Please add some minimal mapping and remapping and usage documentation
At the time of me writing this I have absolutely no idea whatever what the
mappings are for per-line, per-selection or vim gestures to call
coc-pydocstring.  I've already walked through the coc-pydocstring-data which
appears to contain only the virtualenv used by your plugin to wrap calls to
doq.  I've already walked through the node-modules/coc-pydocstring path even
though I don't really know anything about coc modules and know little about the
node-coc-neovim plugin stack, which makes this exploration very slow for me.
I still haven't figured out where the vimscript command mappings are, there is
no vim documentation that I can find, and absolutely no hint that these
commands even exist other than the brief mention in the README.md.
I love your plugin, you've done a better job than I could have done with
implementation of a coc plugin, but I can't use anything except :CocCommand pydocstring-file to make it work.    Even the animated gif is missing any kind of
OSD keypress magic to show the viewer what keys are being pressed by the
author.
Thank you for your hard work and contribution!

Thanks for the issue report. I've added an example keymap to the README.


add load model and fetch model

Adding load_model function to load models from hugging face.

This is the first version of the new design concept to get models from hugging face

Thanks for this @Mu-Magdy and @henrykironde. My concern with this design is that every time we add a new model we'll have to update the code in the core package, make a release, and have users install that new release to access the new model. Ideally we'd be able to release a new model and have users can keep using their current installs and just pass load_model() a new model name.
The way that hugging face solves this problem in huggingface_hub is to default to naming all models the same. So most model repositories have either (or both) of pytorch_model.bin or model.safetensors (these are just alternative formats to pt for storing weights). When you run their from_pretrain() method it looks for that file in the repository, downloads it if necessary, and loads the weights.
Our models don't follow a consistent name scheme, so we would need to change the names of the models to make them the same across repos. We have one .pl model and the others are .pt, so we'd probably have to check both and catch the 404 for the one that isn't there, at least until we update everything to a consistent format. We'd also need to make sure that having the same names doesn't cause issues with fetch_model(). Alternatively we could give the models the same name as the repository. So the model in "weecology/deepforest-tree" would be named "deepforest-tree.pt" and then when we call `model.load_model("weecology/deepforest-tree") we can extract the name of the model file from the repository string.
Ideally we'd be able to just use huggingface_hub directly with the class mixin, but I confirmed @bw4sz thought from this afternoon that the current model structure doesn't work, probably do to the lack of the model.forward() method.

Actually, I was wrong, the hugging_face mixin just works. I got confused because use_release() operates in place but from_pretrain() returns a new object. I think we can just use hugging_face hub. I imported the mixin:
from huggingface_hub import PyTorchModelHubMixin

and added the mixin to the class definition:
class deepforest(pl.LightningModule, PyTorchModelHubMixin):

And this now works:
model = main.deepforest().from_pretrained("ethanwhite/df-test")

To make the huggingface repo I just did basically what @bw4sz suggested this afternoon:
from deepforest import main

model = main.deepforest()
model.use_release()
model.save_pretrained('hfmodel')

I then uploaded the config.json and model.safetensors files to https://huggingface.co/ethanwhite/df-test/ (we could also use model.push_to_hub() if we setup local auth correctly).
So, I think my suggestion now is to just move to:

using huggingface_hub
have the load_model() method be a wrapper around from_pretrained()
update the docs to model = main.deepforest().load_model("weecology/deepforest-tree")

This lets us add models without needing to update the package, avoids adding much new custom code, let's us get rid of fetch_model(), and gets us the version handling that @henrykironde mentioned this afternoon because from_pretrained() has  a revision argument that lets you specify tags and even commit hashes for reproducible analyses.

HI @ethanwhite
in the latest commit i used different approach to download the files just by defining the repo id,
i didn't test it totally and it needs work. but i wanted to know if this way is what you wanted to be used.
In this we can use our own from_pretrained without using the PyTorchModelHubMixin and it can be used for all the models we just need to have the model file and config file have the same name accross all the repos without safetensors or any other extenstion

Hi @ethanwhite
In this commit I use the approach that was discussed on slack.
you can test is using:
import json
from main import deepforest
from huggingface_hub import login

login('') # Hf key token

model = deepforest()

model.load_model('MuMagdy/test_deepforest')
print(model)
print(json.dumps(model.config, indent=4))

this is a repo I made to test containing alll required files.
If the approach is accepted, After unittest and merging we need to upload all the models as model.safetensors (or any other deafult naming HF uses) and all configs to be (config.json).
we can do this simply using:
from huggingface_hub import login
from main import deepforest
login() # Hf key token
model = deepforest.load_from_checkpoint("")
model.push_to_hub(repo_id)

this will make a model.safetensors , config.json and README.md
But the config.json file will be like this
{
  "config_args": null,
  "config_file": "deepforest_config.yml",
  "existing_train_dataloader": null,
  "existing_val_dataloader": null,
  "label_dict": {
    "Tree": 0
  },
  "model": null,
  "num_classes": 1,
  "transforms": null
}

I don't know if this is sufficient for the model or not
I think this will also automate the downlaod counter, because i didn't set it and it is working fine for the repo

In the latest commit all errors are form utilities.use_release() missing so I will add a new commit with use_release again to see if the any other issues errors appears

@Mu-Magdy Thank you so much for this work.


dattcore: Create non-blocking to/from methods for objects with crypto, and asynchronous methods where non-blocking not possible

Sometimes we want to convert a buffer into a crypto object, such as a public key or an extended public key, or our own objects like ContentAuth, but we don't want the to/from methods to block. Unfortunately some of the crypto in the to/from methods do block, such as converting a compressed public key into a pubkey object. We need to create non-blocking methods for these objects.

Anything that involves compressed public keys should have an alternative that uses uncompressed public keys, because converting to/from uncompressed does not do elliptic curve math and thus does not block.
BIP32 extended public keys and private keys have the same issue, plus they also have a checksum in string format.

Fixed in a series of commits that integrate the new fullnode worker interface, particularly from 8b4dd5c to 617e7e7


Format-detection breaks data binding (Apple UIWebView)

I bind a string property text as following:

[[text]]

I run this element in Apple UIWebView. When changing the value of the text property during runtime, the old content partially remains in the
.
I suspect this is caused by UIWebView changing the internal HTML to make the phone numbers clickable. I see the following in the Safari inspector when setting text to +31600000000:

+31600000000

After changing text to +31699999999 this becomes:

+31600000000+31 6 99999999

Workaround: Instruct UIWebView to not auto-detect phone numbers by adding to the header of the HTML file:
<meta name="format-detection" content="telephone=no">

See Apple documentation

Seems like maybe a useful tip for Polymer users, but that is an application specific problem, and not something Polymer would fix for you.

Closing due to age, please reopen if this is still an issue.


chore: update webpack to version 4.16.5

Fixes #37

@skyeckstrom - need to regenerate yarn lockfile


Snapshot and simulators not found

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description

When I launch a fastlane snapshot, my simulators are found (--verbose says 19 simulators found), but I have this error :
File /Users/kevinempociello/Library/Developer/CoreSimulator/Devices/5ADE9DF8-BB93-4AE9-B333-8AF6A0732D69/device.plist not readable! (IOError)
I'm trying to run my UITests on a iPhone 6 Plus.
So, I checked on my simulators list, and yes, I have an iPhone 6 plus, but its identifier is not 5ADE9DF8-BB93-4AE9-B333-8AF6A0732D69 but EB2DC3A0-3C64-4962-A192-2B8DFA9E53B4.
So why fastlane is trying to find the wrong identifier ? Because of iOS versioning ?
My simulators are on iOS 12.2 and 12.4.
Command executed

sudo fastlane snapshot
Complete output when running fastlane, including the stack trace and command used

 ➜  NekRx sudo fastlane snapshot
[✔] 🚀
[17:38:35]: fastlane detected a Gemfile in the current directory
[17:38:35]: however it seems like you don't use `bundle exec`
[17:38:35]: to launch fastlane faster, please use
[17:38:35]:
[17:38:35]: $ bundle exec fastlane snapshot
[17:38:35]:
[17:38:35]: Get started using a Gemfile for fastlane https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile
[17:38:37]: Successfully loaded '/Users/kevinempociello/DEV/NekRx/fastlane/Snapfile' 📄
+----------------------------+-------------------+
|   Detected Values from './fastlane/Snapfile'   |
+----------------------------+-------------------+
| devices                    | ["iPhone 6 Plus"] |
| languages                  | ["en-US"]         |
| scheme                     | NekRx UITests     |
| output_directory           | ./screenshots     |
| clear_previous_screenshots | true              |
+----------------------------+-------------------+
[17:38:37]: $ xcodebuild -showBuildSettings -workspace ./NekRx.xcworkspace -scheme NekRx\ UITests
+----------------------------+------------------------------------------+
|                     Summary for snapshot 2.131.0                      |
+----------------------------+------------------------------------------+
| workspace                  | ./NekRx.xcworkspace                      |
| output_directory           | /Users/kevinempociello/DEV/NekRx/screen  |
|                            | shots                                    |
| devices                    | ["iPhone 6 Plus"]                        |
| languages                  | ["en-US"]                                |
| launch_arguments           | [""]                                     |
| output_simulator_logs      | false                                    |
| skip_open_summary          | false                                    |
| skip_helper_version_check  | false                                    |
| clear_previous_screenshots | true                                     |
| reinstall_app              | false                                    |
| erase_simulator            | false                                    |
| localize_simulator         | false                                    |
| app_identifier             | com.nekkar.NekRx                         |
| buildlog_path              | ~/Library/Logs/snapshot                  |
| clean                      | false                                    |
| scheme                     | NekRx UITests                            |
| number_of_retries          | 1                                        |
| stop_after_first_error     | false                                    |
| result_bundle              | false                                    |
| concurrent_simulators      | true                                     |
| xcode_path                 | /Applications/Xcode.app                  |
+----------------------------+------------------------------------------+
[17:38:39]: Clearing previously generated screenshots
[17:38:39]: Building and running project - this might take some time...
[17:38:39]: Patching simulators '/Users/kevinempociello/Library/Preferences/com.apple.iphonesimulator.plist' to scale to 100%
Looking for related GitHub issues on fastlane/fastlane...
Found no similar issues. To create a new issue, please visit:
https://github.com/fastlane/fastlane/issues/new
Run fastlane env to append the fastlane environment to your issue
/Library/Ruby/Gems/2.3.0/gems/CFPropertyList-3.0.1/lib/cfpropertylist/rbCFPropertyList.rb:333:in load': [!] File /Users/kevinempociello/Library/Developer/CoreSimulator/Devices/5ADE9DF8-BB93-4AE9-B333-8AF6A0732D69/device.plist not readable! (IOError) 	from /Library/Ruby/Gems/2.3.0/gems/CFPropertyList-3.0.1/lib/cfpropertylist/rbCFPropertyList.rb:238:in initialize'
from /Library/Ruby/Gems/2.3.0/gems/simctl-1.6.5/lib/simctl/device.rb:233:in new' 	from /Library/Ruby/Gems/2.3.0/gems/simctl-1.6.5/lib/simctl/device.rb:233:in plist'
from /Library/Ruby/Gems/2.3.0/gems/simctl-1.6.5/lib/simctl/device.rb:38:in devicetype' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:96:in block in get_device_type_with_simctl'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:93:in map' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:93:in get_device_type_with_simctl'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:61:in verify_devices_share_os' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:36:in destination'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/test_command_generator.rb:15:in generate' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:85:in launch_simultaneously'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:70:in block (3 levels) in take_screenshots_simultaneously' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:69:in each'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:69:in block (2 levels) in take_screenshots_simultaneously' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:46:in each'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:46:in each_with_index' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:46:in block in take_screenshots_simultaneously'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:45:in each' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb:45:in take_screenshots_simultaneously'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/runner.rb:45:in work' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/commands_generator.rb:40:in block (2 levels) in run'
from /Library/Ruby/Gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:178:in call' 	from /Library/Ruby/Gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/command.rb:153:in run'
from /Library/Ruby/Gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/runner.rb:476:in run_active_command' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in run!'
from /Library/Ruby/Gems/2.3.0/gems/commander-fastlane-4.4.6/lib/commander/delegates.rb:15:in run!' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/commands_generator.rb:104:in run'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/snapshot/lib/snapshot/commands_generator.rb:14:in start' 	from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/fastlane/lib/fastlane/cli_tools_distributor.rb:111:in take_off'
from /Library/Ruby/Gems/2.3.0/gems/fastlane-2.131.0/bin/fastlane:23:in <top (required)>' 	from /usr/local/bin/fastlane:22:in load'
from /usr/local/bin/fastlane:22:in `'

Environment

 🚫 fastlane environment 🚫
Stack

Key
Value

OS
10.14.6

Ruby
2.3.7

Bundler?
false

Git
git version 2.20.1 (Apple Git-117)

Installation Source
/usr/local/bin/fastlane

Host
Mac OS X 10.14.6 (18G95)

Ruby Lib Dir
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib

OpenSSL Version
LibreSSL 2.6.5

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
10.3

System Locale

Error

No Locale with UTF8 found 🚫

fastlane files:
`./fastlane/Fastfile`
# This file contains the fastlane.tools configuration
# You can find the documentation at https://docs.fastlane.tools
#
# For a list of all available actions, check out
#
#     https://docs.fastlane.tools/actions
#
# For a list of all available plugins, check out
#
#     https://docs.fastlane.tools/plugins/available-plugins
#

# Uncomment the line if you want fastlane to automatically update itself
# update_fastlane

default_platform(:ios)

platform :ios do
  desc "Create app on Apple Developer and App Store Connect site"
  lane :create_app do
    produce
  end

  desc "Take screenshots"
  lane :screenshot do
    snapshot
  end

  desc "Create IPA"
  lane :build do
    enable_automatic_code_signing
    increment_build_number
    gym
  end

end

`./fastlane/Appfile`
app_identifier("com.nekkar.NekRx") # The bundle identifier of your app
<EMAIL_ADDRESS># Your Apple email address
itc_team_id(82505800)

# For more information about the Appfile, see:
#     https://docs.fastlane.tools/advanced/#appfile

fastlane gems

Gem
Version
Update-Status

fastlane
2.131.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

did_you_mean
1.0.0

slack-notifier
2.3.2

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

unicode-display_width
1.6.0

terminal-table
1.8.0

plist
3.5.0

multipart-post
2.0.0

word_wrap
1.0.0

public_suffix
2.0.5

tty-screen
0.7.0

tty-cursor
0.7.0

tty-spinner
0.9.1

babosa
1.0.2

colored
1.2

highline
1.7.10

commander-fastlane
4.4.6

excon
0.66.0

faraday
0.15.4

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

gh_inspector
1.1.3

mini_magick
4.9.5

multi_xml
0.6.0

security
0.1.3

xcpretty-travis-formatter
1.0.0

dotenv
2.7.5

bundler
2.0.2

faraday_middleware
0.13.1

naturally
2.2.0

simctl
1.6.5

jwt
2.1.0

uber
0.1.0

declarative
0.0.10

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.2

multi_json
1.13.1

signet
0.11.0

memoist
0.16.0

os
1.0.1

googleauth
0.6.7

httpclient
2.8.3

google-api-client
0.23.9

digest-crc
0.4.1

google-cloud-storage
1.16.0

emoji_regex
1.0.1

json
2.2.0

io-console
0.4.5

rubyzip
1.2.4

CFPropertyList
3.0.1

libxml-ruby
2.9.0

atomos
0.1.3

colored2
3.1.2

nanaimo
0.2.6

xcodeproj
1.12.0

claide
1.0.3

fastimage
2.1.7

addressable
2.7.0

psych
<IP_ADDRESS>

mime-types
3.3

mime-types-data
3.2019.0904

generated on: 2019-09-13

Hm, quickly looked into this:
https://github.com/fastlane/fastlane/blob/f32b007ff45e648b37b6c9c2037ac481f36b7780/snapshot/lib/snapshot/test_command_generator.rb#L87-L96
The last line of code from fastlane involved here is 96, then line 38 from this:
https://github.com/plu/simctl/blob/26e8d151b489c8b278f0e1d2ad810d79021714e8/lib/simctl/device.rb#L37-L39
then 233 here:
https://github.com/plu/simctl/blob/26e8d151b489c8b278f0e1d2ad810d79021714e8/lib/simctl/device.rb#L233
Probably the device_names fastlane is using is already broken or containing info that will lead to error.
This comes from here:
https://github.com/fastlane/fastlane/blob/f32b007ff45e648b37b6c9c2037ac481f36b7780/snapshot/lib/snapshot/simulator_launchers/simulator_launcher.rb#L59-L70
Do you maybe have a broken simulator somewhere that could be selected here for some reason? Can you try to clean that up? Is probably easier than us continue debugging where it might get a device that it should not use :/

@janpio first, thank you so much for the time spent on my problem !
I looked into the files, Fastlane is using ** simctl** to get the simulators, that's pretty normal.
So if my device_names are wrong, it's certain that Fastlane will block.
So I tried to use simctl on my own first to get the devices list with :
$ xcrun simctl list
But the simulator identifier used by Fastlane is not listed !
Even if I try some things like :
xcrun simctl erase 5ADE9DF8-BB93-4AE9-B333-8AF6A0732D69
(which is the identifier used by Fastlane, the one causing the bug). The system tell me
Invalid device
I'm sure that Fastlane is not inventing this identifier. So we can imagine that the Ruby code and the command system simctl are not finding the same simulators list.
Do you have an idea how to compare these two methods ?

I think this is the underlying function: https://github.com/fastlane/fastlane/blob/cf52a29dc62e07c2b5a690b4b74e0b45c7754af8/fastlane_core/lib/fastlane_core/device_manager.rb#L14-L66

Okay, actually
xcrun simctl list devices
and
sudo xcrun simctl list devices
don't display the same devices. The identifier was coming from this difference.
Stop to use : sudo fastlane snapshot and use fastlane snapshot was the solution.
Even if from this point, fastlane wasn't able to get access to some files (little chmod(s) and it was okay).
I'm facing a last problem, the UITests are running well with fastlane snapshot (I can see it in the simulators), but fastlane is not taking any screenshot.
Everything is executing well, expect the red cross in the language section.

INFO [2019-09-21 00:08:46.37]: ▸ All tests
INFO [2019-09-21 00:08:46.37]: ▸ Test Suite NYL2PronosUITests.xctest started
INFO [2019-09-21 00:08:46.38]: ▸ NYL2PronosUITests
INFO [2019-09-21 00:08:58.09]: ▸     ✓ testExample (11.713 seconds)
INFO [2019-09-21 00:08:58.10]: ▸ 	 Executed 1 test, with 0 failures (0 unexpected) in 11.713 (11.715) seconds
INFO [2019-09-21 00:08:58.10]: ▸
INFO [2019-09-21 00:08:58.37]: ▸ 2019-09-21 00:08:58.371 xcodebuild[53523:2991315] [MT] IDETestOperationsObserverDebug: 25.976 elapsed -- Testing started completed.
INFO [2019-09-21 00:08:58.37]: ▸ 2019-09-21 00:08:58.372 xcodebuild[53523:2991315] [MT] IDETestOperationsObserverDebug: 0.000 sec, +0.000 sec -- start
INFO [2019-09-21 00:08:58.37]: ▸ 2019-09-21 00:08:58.372 xcodebuild[53523:2991315] [MT] IDETestOperationsObserverDebug: 25.976 sec, +25.976 sec -- end
INFO [2019-09-21 00:08:58.48]: ▸ Test Succeeded
+----------+-------+
| snapshot results |
+----------+-------+
| Device   | en-US |
+----------+-------+
| iPhone 8 |  ❌   |
+----------+-------+
INFO [2019-09-21 00:09:04.55]: Generating HTML Report
INFO [2019-09-21 00:09:04.55]: Successfully created HTML file with an overview of all the screenshots: '/Users/kevinempociello/DEV/NYL2Pronos-iOS/NYL2Pronos/fastlane/screenshots/screenshots.html'
INFO [2019-09-21 00:09:05.93]: Successfully generated documentation at path '/Users/kevinempociello/DEV/NYL2Pronos-iOS/NYL2Pronos/fastlane/README.md'
+------+---------------------+-------------+
|             fastlane summary             |
+------+---------------------+-------------+
| Step | Action              | Time (in s) |
+------+---------------------+-------------+
| 1    | default_platform    | 0           |
| 2    | capture_screenshots | 124         |
+------+---------------------+-------------+
INFO [2019-09-21 00:09:05.94]: fastlane.tools finished successfully 🎉

Okay, actually
xcrun simctl list devices
and
sudo xcrun simctl list devices
don't display the same devices. The identifier was coming from this difference.

Interesting. Do you know why this might be the case?
Anything we can do to work around this?
For your other problem best open a new issue and include your testing script.

The solution was to remove the sudo.
and use : fastlane snapshot instead.
From this point, various files was only available for root and not for my user.
I changed these files rights with chmod, and my fastlane snapshot worked !


Compile failure with base-4.7

Hi, I noticed the compile failure below
Configuring component lib from fastparser-0.3.0...
Preprocessing library fastparser-0.3.0...
[1 of 1] Compiling ByteString.Parser.Fast ( src/ByteString/Parser/Fast.hs, /tmp/matrix-worker/1495789579/dist-newstyle/build/x86_64-linux/ghc-7.8.4/fastparser-0.3.0/build/ByteString/Parser/Fast.o )

src/ByteString/Parser/Fast.hs:130:10:
    Not in scope: type constructor or class ‘Monoid’
    Perhaps you meant ‘Monad’ (imported from Control.Monad)

(Monoid moved into Prelude only with base-4.8 as a side-effect of the FTP/AMP/Semigroup-Monoid proposals)
I already revised the meta-data at https://hackage.haskell.org/package/fastparser-0.3.0/revisions/ so there's no need to upload a new release just for the metadata.

Thanks a lot, I will fix that for the next revisions!


Clarify Baggage metadata exposure

Although Baggage entry metadata is not used extensively these days, in the future we will need to use/expose this.  Just wanted to clarify that this has been taken into account for the mid term future (it sounds like you did but wanted to double verify anyway).
Probably Manager.raw_entries() will in the future become public, or you will add a Manager.value_full() or similar function?

It is likely that we'll expose Manager.raw_entries() in the future. The API does not yet specify a mechanism to access the metadata, however we require it for the default (W3C) text map propagator, so we chose to tag raw_entries as @api private until an appropriate operation is added to the spec.

Makes sense! Thanks!


Bump nu.validator.validator to v15.3.28

Fixes #81.

FYI I have another minor release on the way soon, to fix a couple of regressions I introduced in the v15.3.28 release

Noted. Thanks for the heads-up.


Port 1433 for Lakehouse connectivity

Can we update the article to include the port numbers for Lakehouse connectivity.

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

ID: f4daef9a-341c-696a-1d19-de05ffd67588
Version Independent ID: 7cd18c28-7227-488a-aa28-6b869058e715
Content: Adjust communication settings for the on-premises data gateway
Content Source: data-integration/gateway/service-gateway-communication.md
Product: on-premises-data-gateway
GitHub Login: @miquelladeboer
Microsoft Alias: mideboer

Please reference https://community.fabric.microsoft.com/t5/Dataflows/Dataflow-Gen2-Issue/td-p/3256928 for official confirmation.
Are there any other items that should be adjusted in this article to account for Fabric scenarios?

We think this is covered here as a troubleshooting FAQ:
https://learn.microsoft.com/en-us/fabric/data-factory/gateway-considerations-output-destinations#network-issues-with-port-1433

Network issues with port 1433
When using Microsoft Fabric Dataflow Gen2 with an on-premises data gateway, you might encounter issues with the dataflow refresh process. The underlying problem occurs when the gateway is unable to connect to the dataflow staging Lakehouse in order to read the data before copying it to the desired data destination. This issue can occur regardless of the type of data destination being used.

In my experience Fabric customers have little visibility into that separate FAQ page. They expect all network requirements to be consolidated within this page.
This is not to say that separate FAQ is not useful - it is. However, its relevant aspects need to IMO be integrated into the main doc.

@vitalymct Fabric is still in preview, so potentially the requirements will change, so we didn't blend in Preview content with GA content. It's good feedback and we should consider it soon.

Thanks @itsnotaboutthecell for your dedication to our documentation. Unfortunately, at this time we have been unable to review your issue in a timely manner and we sincerely apologize for the delayed response. The requested updates have not been made since the creation of this issue, and the timeline for resolution may vary based on resourcing, so we've created an internal work item to incorporate your suggestions. We are closing this issue for now, but feel free to comment here as necessary. #please-close


Adding wallet dropdowns to header

Adds the initial dropdown menu items:

Closing this as stale, header work will be picked out of this branch and rolled in to the current implementation


Add clean parameter

This PR adds a clean parameter, which allows to clean the certificate from the CA upon destroying it.
This is useful to keep the CA clean. It requires to add a rule to auth.conf on the CA, for example by allowing certificates to clean themselves:
        {
            # Allow nodes to delete their own certificate
            match-request: {
                path: "^/puppet-ca/v1/certificate(_status|_request)?/([^/]+)$"
                type: regex
                method: [delete]
            }
            allow: "$2"
            sort-order: 500
            name: "c2c puppet cert clean"
        },

Together with #3 and #4, this allows to set up automatic renewal of Puppet certificates, with something along the lines of:
    file { "${confdir}/puppet/csr_attributes.yaml":
      ensure  => file,
      owner   => 'root',
      group   => 'root',
      mode    => '0440',
      content => template('blah/csr_attributes.yaml.erb'),
    }
    ~> puppet_certificate { $certname:
      ensure               => valid,
      waitforcert          => 60,
      renewal_grace_period => 20,
      clean                => true,
    }

@reidmv added a description here, too. It should give you an idea of what #3, #4 and #5 achieve together (I plan on writing a blog post on what we're doing with that once it's merged).


beast::tcp_stream timeout results in CLOSE_WAIT state

Beast version: 300
Boost version: 1.74.0
When compiling a file server using Beast and Asio with g++10, I have an odd issue.
A developer is using Axios to build a rudimentary front-end to test some functionality. I noticed that the sockets aren't being closed, and are rather timing out.
I'm using:
stream_.expires_after(std::chrono::seconds(1));
a fairly fast timeout until it's deemed we need otherwise.  I initially noticed this with a 30 second timeout.
The problem is, when I try to access this page through localhost on Chrome or Chromium based browsers, the sockets hang in the CLOSE_WAIT state.  I confirmed this with netstat.
If I use Firefox, the "timed-out" sockets transition to the TIME_WAIT state.
TIME_WAIT isn't a problem since I'm using allow_reuse, however CLOSE_WAIT is a problem.  From what I'm seeing, it would be pretty easy to DOS this server by just opening a bunch of client side sockets until I hit the 1024 FD limit.
Is this expected behaviour? Is there an option I should be using or something to avoid this? Is timeout the right tool for this? This problem doesn't happen when I curl the endpoints. When using Curl, my server detects shutdown_send, and cleans the socket up appropriately.
It's the client-side part that hangs open, clogging things up with the CLOSED_WAIT state.
FYI, I've gone through the Chat Server example and picked things out to get to this point.
Thanks for the help. I appreciate it.

Yes that's normal for Chrome. The browser does not close connections gracefully.

Yes that's normal for Chrome. The browser does not close connections gracefully.

Thanks very much for the quick reply!
Do you have any suggestions on how to avoid CLOSE_WAIT sockets piling up if a client decides to misbehave and never send FIN?  I've been deep in the weeds with documentation including different socket options but nothing is jumping out at me.
Is this just a weakness of a TCP server due to the restrictions of the RFC?

Thanks very much for the quick reply!
Do you have any suggestions on how to avoid CLOSE_WAIT sockets piling up if a client decides to misbehave and never send FIN?  I've been deep in the weeds with documentation including different socket options but nothing is jumping out at me.
Is this just a weakness of a TCP server due to the restrictions of the RFC?

You can remove the CLOSE_WAIT state by manually closing the socket on the server end.
This state indicates that the OS knows that there will be no more communication on this socket but your program hasn't released the last handle to it.

You can remove the CLOSE_WAIT state by manually closing the socket on the server end.
This state indicates that the OS knows that there will be no more communication on this socket but your program hasn't released the last handle to it.

CLOSE_WAIT doesn't bother servers the same way it bothers clients, so I would not worry about it.

CLOSE_WAIT doesn't bother servers the same way it bothers clients, so I would not worry about it.

You can remove the CLOSE_WAIT state by manually closing the socket on the server end.
This state indicates that the OS knows that there will be no more communication on this socket but your program hasn't released the last handle to it.

I could try that with a manual timeout and forcing a close.

CLOSE_WAIT doesn't bother servers the same way it bothers clients, so I would not worry about it.

I suspect this is correct. I created a mini torture test where I opened and hung 20k connections simultaneously. The dangling CLOSE_WAIT didn't appear to be a problem. I'll need to do some reading to understand why the server can deal with this, but thank you both for pointing me in the right direction.

You can remove the CLOSE_WAIT state by manually closing the socket on the server end.
This state indicates that the OS knows that there will be no more communication on this socket but your program hasn't released the last handle to it.

I could try that with a manual timeout and forcing a close.

CLOSE_WAIT doesn't bother servers the same way it bothers clients, so I would not worry about it.

I suspect this is correct. I created a mini torture test where I opened and hung 20k connections simultaneously. The dangling CLOSE_WAIT didn't appear to be a problem. I'll need to do some reading to understand why the server can deal with this, but thank you both for pointing me in the right direction.


Cronjob service and cronDAO fixes

Cronjobs were not being stored in the cronDAO in the backend.

@kgrgreer Client.js file remove :+1:


Add and use internal X509_add_certs_new(), which simplifies matters

This has been extracted from #13070.

Rebased to solve a merge conflict.

Rebased to solve merge conflicts

Can we please handle this soon?
It keeps suffering from merge conflicts,
which I just solved for the third time.

According to #12964  it should be named ossl_x509_add_certs_new().

Done.
Consequently, also renamed X509_add_cert_new() to ossl_x509_add_cert_new().

The renaming is not necessary since the old name was not exported from the library.

Yeah, the renaming was just for better adherence to the internal naming conventions.

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged - thanks @t8m


Server side render is significantly slower than the 1 axios call that it's running

Version
v2.4.0
Reproduction link
https://github.com/kalenjordan/nuxt-test/blob/master/pages/home.vue#L93
Steps to reproduce

Go to https://pros.global/
Open up network tab and look at the time for initial page response

What is expected ?
The initial page response should be roughly as long as the API call to grab the users for the home page, which is about 130ms - https://api.pros.global/api/v1/saved-searches/home?with_users=1

What is actually happening?
The initial page response is much longer than expected: ~1800ms.
Note that in my local development environment this doesn't happen. Only happens in production (digitalocean).
Additional notes
It seems to be much slower when running in production mode (npm run start) vs. dev mode (npm run dev) in the production environment. Response time is more like 500ms or 600ms when it's run in dev mode.

This bug report is available on Nuxt community (#c8694)

Hi @kalenjordan. I've seen your code. It seems you are not using axios-module. As a best practice, the baseURL for SSR renders should be different than browserBaseURL. So that backend API calls are over the plain HTTP. Also using LRU cache.
BTW this issue should be investigated more. I suggest doing this:

Use curl in your DO ssh to test request time to the API
Test against a page without requests in asyncData to see how it differs. Is bottleneck the SSR phase or requests

Thanks for the quick reply @pi0! Hmm I think I am using the axios module?
https://github.com/kalenjordan/nuxt-test/blob/master/nuxt.config.js#L65
Noted on baseURL - that's something I need to look into.
On the curl point - that's actually something I was just trying. It is actually significantly faster over curl and also generally on first page view with an incognito browser - there seems to be something happening with a cookie or session to slow things down.
I have tested with asyncData disabled and it's definitely way faster.

@kalenjordan You have it in your module list, but you don't use it.
 async asyncData(context) {
            if (!process.server) {
                return {homeSavedSearch: {users: []}};
            }
            // You can set the base URL in your nuxt config
            let url = process.env.API_URL + 'saved-searches/home?with_users=1';
            return context.$axios.get(url)
                .then((response) => {
                    return {
                        homeSavedSearch: response.data,
                    }
                })
        },

It is actually significantly faster over curl and also generally on first-page view with an incognito browser. there seems to be something happening with a cookie or session to slow things down.

I think so. The bottleneck may be the authentication middleware for the backend.

I updated my nuxt app to use the $axios community module properly. Unfortunately it doesn't seem like I can hit the http API for server side render because the app serving the api is setup to redirect all http requests to https.


Fixing test case for date and time

Additional fixes for the date and time test case.

Closing as it is out of date.


After reinstall, the billing API approval page is not present

After reinstall, the billing API approval page is not present. Uninstalling and reinstalling the app on the same store should result in the same process as installing an app for the first time, so the billing approval page should appear after OAuth.
If you have already approved a billing plan, then reinstall the app, the billing approval page does not show, like in the below video:
https://screenshot.click/09-00-3d0sp-fdw6l.mp4
Note: This is an issue that will have your app rejected by Shopify

@fyroc Did your app uninstall webook get triggered?  There’s some logic in there to cleanup after an uninstall.

The uninstall webhook is needed in this case. It will mark the shop as trashed, and trash and cancell all charges.
On re-install, it restores the shop, and presents the billing screen.

Awesome, thanks. I guess it would help if I had the correct URL pointed at the web hook.

@brianakidd @ohmybrew The app uninstall is working. The Store is being soft deleted correctly, however, the billing page is not coming up when I try to install again.

is the recent charge for that shop marked as "cancelled"?
On Tue, Oct 9, 2018 at 4:28 PM Cory Fail<EMAIL_ADDRESS>wrote:

@brianakidd https://github.com/brianakidd @ohmybrew
https://github.com/ohmybrew The app uninstall is working. The Store is
being soft deleted correctly, however, the billing page is not coming up
when I try to install again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-428310101,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTuOlq7B4wRUnhEMm_2Q8B82W-V3CBrks5ujPG4gaJpZM4XT1rG
.

--
Thanks,
Tyler King

It is marked as cancelled.

11<PHONE_NUMBER>	1	cancelled	Freemium	Free to install but a $2 charge per every 100 emails used	1	0.00	5000.00	0	2018-10-09 00:00:00	2018-10-09 00:00:00	2018-10-09 00:00:00	2018-10-09 00:00:00	2018-10-09 19:04:42	2018-10-09 19:06:35	NULL	10	3	NULL	NULL

Ugh I know the issue. Since updating to plan-based things, I don't rely on this cancel status anymore. I need to update the uninstall webhook job to kill the plan ID assigned to the shop... will work on this tonight, add the tests and release a patch.

Just pushed up a commit with a fix for this, but want to do a real-world test before I release. Will do one tonight.

@ohmybrew did you get this released? This is the last thing I need done before I can submit one of my apps. Thanks for your hard work!

I have not yet. Ended up not feeling good today so I've been stuck on the
couch :/ I'll give it a go tomorrow morning if possible. You're welcome to
point composer to master and try it if you like for now, and see if all is
well with the fix
On Wed., Oct. 10, 2018, 00:43 Cory Fail<EMAIL_ADDRESS>wrote:

@ohmybrew https://github.com/ohmybrew did you get this released? This
is the last thing I need done before I can submit one of my apps. Thanks
for your hard work!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-428423582,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTuOoCEwp6t2wGBRAJOPZndUfWZLdBMks5ujWXMgaJpZM4XT1rG
.

@ohmybrew after updating composer to Master, I'm still having the issue

So you're,

Installing
Accepting billing
Uninstalling
Reinstalling
No bill screen?

Did the plan_id get nulled on uninstall?
On Thu., Oct. 11, 2018, 13:09 Cory Fail<EMAIL_ADDRESS>wrote:

@ohmybrew https://github.com/ohmybrew after updating composer to
Master, I'm still having the issue
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-429002939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTuOsjEzg29hFcOP4ehM_WaX496gOd4ks5uj2YagaJpZM4XT1rG
.

It did not

Hmm that would be why. Are you using the default uninstall job? I added
onto one of the method which clears the token to also clear the plan
attached to the shop
On Thu., Oct. 11, 2018, 13:40 Cory Fail<EMAIL_ADDRESS>wrote:

It did not
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-429016763,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTuOqC6AnWEB89p2q5xFJHIzok73TQJks5uj21ygaJpZM4XT1rG
.

I have not changed the uninstall job. Can you try testing it and releasing
it yourself? Maybe it has something to do with me using the master branch
on production
On Thu, Oct 11, 2018 at 12:16 PM Tyler King<EMAIL_ADDRESS>wrote:

Hmm that would be why. Are you using the default uninstall job? I added
onto one of the method which clears the token to also clear the plan
attached to the shop
On Thu., Oct. 11, 2018, 13:40 Cory Fail<EMAIL_ADDRESS>wrote:

It did not
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-429016763
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ACTuOqC6AnWEB89p2q5xFJHIzok73TQJks5uj21ygaJpZM4XT1rG
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-429018802,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGsrEKly6fNceysH-PWStDfAyvD1uIXuks5uj27SgaJpZM4XT1rG
.

--
Cory C. Fail
Software Engineer
coryfail.com /<PHONE_NUMBER>

@fyroc Are you sure the uninstall job was triggered?

I'm going to spin up a fresh Heroku instance and give it a whirl.

If it wasn’t firing then the shop would not be soft deleting and the charge
would not be canceled
On Thu, Oct 11, 2018 at 12:59 PM Brian Kidd<EMAIL_ADDRESS>wrote:

@fyroc https://github.com/fyroc Are you sure the uninstall job was
triggered?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ohmybrew/laravel-shopify/issues/122#issuecomment-429035475,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGsrEIfMXBrq3HSiR-l9UKOyv-10DJuWks5uj3jggaJpZM4XT1rG
.

--
Cory C. Fail
Software Engineer
coryfail.com /<PHONE_NUMBER>

@fyroc It seems to be working in my case, are you sure composer updated the package?
Video: https://streamable.com/m1qj6

Shows clean database
Installs app
Accept billing
Shows shop in database with plan
Uninstalls app
Shows shop now soft deleted and plan is now null
Reinstalls, accepts billing
Shows shop with plan again

@fyroc It seems to be working in my case, are you sure composer updated the package?
Video: https://streamable.com/m1qj6

Shows clean database
Installs app
Accept billing
Shows shop in database with plan
Uninstalls app
Shows shop now soft deleted and plan is now null
Reinstalls, accepts billing
Shows shop with plan again

I'm not sure if it did since I can only test on a my production server. If it works for you, go ahead and release and I'll test again.

Yeah I rolled back to the commit before, re-tested, and yes, billing never showed up, master, it did. So I think we're ok... will release shortly, thanks!

v4.0.5 tagged. Thanks :)

This is fixed now.
I also want to add the note to make sure your restart your Queue Works since they do cache the old code


wal: treat dir with unrelated files as empty

fixes #2571
/cc @barakmich @kelseyhightower @xiang90

can we move that out of wal? it should not be inside wal pkg.

@xiang90 I need some time to do the move.

LGTM. rename all walversion -> datadir version

print out warning if there is unrelated files inside the data dir.

Current behavior:
$ tree -la 1.etcd
1.etcd
├── .aaa
unihorn@CoreOS ~/g/s/g/c/etcd> ./bin/etcd --data-dir 1.etcd                         fix-detect-wal!?
2015/03/24 18:38:00 etcd: found invalid file/dir .aaa under data dir 1.etcd (Ignore this if you are upgrading etcd)
2015/03/24 18:38:00 etcd: listening for peers on http://localhost:2380
2015/03/24 18:38:00 etcd: listening for peers on http://localhost:7001
2015/03/24 18:38:00 etcd: listening for client requests on http://localhost:2379
2015/03/24 18:38:00 etcd: listening for client requests on http://localhost:4001
*2015/03/24 18:38:00 etcdserver: datadir is valid for the 2.0.1 format*
*2015/03/24 18:38:00 etcdserver: extra file .aaa found in data-dir 1.etcd*
2015/03/24 18:38:00 etcdserver: name = default
2015/03/24 18:38:00 etcdserver: data dir = 1.etcd
2015/03/24 18:38:00 etcdserver: member dir = 1.etcd/member
2015/03/24 18:38:00 etcdserver: heartbeat = 100ms
2015/03/24 18:38:00 etcdserver: election = 1000ms
2015/03/24 18:38:00 etcdserver: snapshot count = 10000
2015/03/24 18:38:00 etcdserver: advertise client URLs = http://localhost:2379,http://localhost:4001
2015/03/24 18:38:00 etcdserver: initial advertise peer URLs = http://localhost:2380,http://localhost:7001
2015/03/24 18:38:00 etcdserver: initial cluster = default=http://localhost:2380,default=http://localhost:7001
2015/03/24 18:38:00 etcdserver: start member ce2a822cea30bfca in cluster 7e27652122e8b2ae
2015/03/24 18:38:00 INFO: raft: ce2a822cea30bfca became follower at term 0
2015/03/24 18:38:00 INFO: raft: newRaft ce2a822cea30bfca [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
2015/03/24 18:38:00 INFO: raft: ce2a822cea30bfca became follower at term 1
2015/03/24 18:38:00 etcdserver: added local member ce2a822cea30bfca [http://localhost:2380 http://localhost:7001] to cluster 7e27652122e8b2ae
2015/03/24 18:38:01 INFO: raft: ce2a822cea30bfca is starting a new election at term 1
2015/03/24 18:38:01 INFO: raft: ce2a822cea30bfca became candidate at term 2
2015/03/24 18:38:01 INFO: raft: ce2a822cea30bfca received vote from ce2a822cea30bfca at term 2
2015/03/24 18:38:01 INFO: raft: ce2a822cea30bfca became leader at term 2
2015/03/24 18:38:01 INFO: raft.node: ce2a822cea30bfca elected leader ce2a822cea30bfca at term 2
2015/03/24 18:38:01 etcdserver: published {Name:default ClientURLs:[http://localhost:2379 http://localhost:4001]} to cluster 7e27652122e8b2ae

Thanks you from removing the printing of the extra files. We can educate people on the expectation of the datadir and provide docs on why a clean data dir is important, but not mandatory.