firebase_app_distribution fails to execute, with no details

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

Cannot run firebase_app_distribution, the script just ends with a Couldn't find binary error
Command executed

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

ERROR [2021-07-14 16:20:25.08]: fastlane finished with errors
bundler: failed to load command: fastlane (/Users/grainchain/.rbenv/versions/2.6.6/bin/fastlane)
Traceback (most recent call last):
        43: from /Users/grainchain/.rbenv/versions/2.6.6/bin/bundle:23:in `<main>'
        42: from /Users/grainchain/.rbenv/versions/2.6.6/bin/bundle:23:in `load'
        41: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/exe/bundle:37:in `<top (required)>'
        40: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/friendly_errors.rb:128:in `with_friendly_errors'
        39: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/exe/bundle:49:in `block in <top (required)>'
        38: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:24:in `start'
        37: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        36: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:30:in `dispatch'
        35: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        34: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        33: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        32: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:474:in `exec'
        31: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:28:in `run'
        30: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:63:in `kernel_load'
        29: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:63:in `load'
        28: from /Users/grainchain/.rbenv/versions/2.6.6/bin/fastlane:23:in `<top (required)>'
        27: from /Users/grainchain/.rbenv/versions/2.6.6/bin/fastlane:23:in `load'
        26: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/bin/fastlane:23:in `<top (required)>'
        25: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/cli_tools_distributor.rb:122:in `take_off'
        24: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:42:in `start'
        23: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:353:in `run'
        22: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
        21: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in `run!'
        20: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
        19: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
        18: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
        17: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:109:in `block (2 levels) in run'
        16: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
        15: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
        14: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:45:in `execute'
        13: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:45:in `chdir'
        12: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
        11: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/lane.rb:33:in `call'
        10: from Fastfile:23:in `block (2 levels) in parsing_binding'
         9: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
         8: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
         7: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
         6: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:229:in `chdir'
         5: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
         4: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
         3: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
         2: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-plugin-firebase_app_distribution-0.2.9/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:25:in `run'
         1: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/ui.rb:17:in `method_missing'
/Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/interface.rb:141:in `user_error!': Couldn't find binary (FastlaneCore::Interface::FastlaneError)
        43: from /Users/grainchain/.rbenv/versions/2.6.6/bin/bundle:23:in `<main>'
        42: from /Users/grainchain/.rbenv/versions/2.6.6/bin/bundle:23:in `load'
        41: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/exe/bundle:37:in `<top (required)>'
        40: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/friendly_errors.rb:128:in `with_friendly_errors'
        39: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/exe/bundle:49:in `block in <top (required)>'
        38: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:24:in `start'
        37: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
        36: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:30:in `dispatch'
        35: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
        34: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
        33: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
        32: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli.rb:474:in `exec'
        31: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:28:in `run'
        30: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:63:in `kernel_load'
        29: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/bundler-2.2.23/lib/bundler/cli/exec.rb:63:in `load'
        28: from /Users/grainchain/.rbenv/versions/2.6.6/bin/fastlane:23:in `<top (required)>'
        27: from /Users/grainchain/.rbenv/versions/2.6.6/bin/fastlane:23:in `load'
        26: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/bin/fastlane:23:in `<top (required)>'
        25: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/cli_tools_distributor.rb:122:in `take_off'
        24: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:42:in `start'
        23: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:353:in `run'
        22: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/delegates.rb:18:in `run!'
        21: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:76:in `run!'
        20: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/runner.rb:444:in `run_active_command'
        19: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/command.rb:157:in `run'
        18: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/commander-4.6.0/lib/commander/command.rb:187:in `call'
        17: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/commands_generator.rb:109:in `block (2 levels) in run'
        16: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/command_line_handler.rb:36:in `handle'
        15: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/lane_manager.rb:47:in `cruise_lane'
        14: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:45:in `execute'
        13: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:45:in `chdir'
        12: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
        11: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/lane.rb:33:in `call'
        10: from Fastfile:23:in `block (2 levels) in parsing_binding'
         9: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/fast_file.rb:159:in `method_missing'
         8: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:157:in `trigger_action_by_name'
         7: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:229:in `execute_action'
         6: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:229:in `chdir'
         5: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:255:in `block in execute_action'
         4: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/actions/actions_helper.rb:69:in `execute_action'
         3: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane/lib/fastlane/runner.rb:263:in `block (2 levels) in execute_action'
         2: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-plugin-firebase_app_distribution-0.2.9/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb:25:in `run'
         1: from /Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/ui.rb:17:in `method_missing'
/Users/grainchain/.rbenv/versions/2.6.6/lib/ruby/gems/2.6.0/gems/fastlane-2.187.0/fastlane_core/lib/fastlane_core/ui/interface.rb:141:in `user_error!': [!] Couldn't find binary (FastlaneCore::Interface::FastlaneError)

Environment

✅ fastlane environment ✅
Stack

Key
Value

OS
11.4

Ruby
2.6.6

Bundler?
true

Git
git version 2.30.1 (Apple Git-130)

Installation Source
~/.rbenv/versions/2.6.6/bin/fastlane

Host
macOS 11.4 (20F71)

Ruby Lib Dir
~/.rbenv/versions/2.6.6/lib

OpenSSL Version
OpenSSL 1.1.1k  25 Mar 2021

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

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

Xcode Version
12.5

Swift Version
5.4

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL

LANGUAGE

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 "Deploy to firebase app distribution"
  lane :distribute do
      # increment_build_number(xcodeproj: "silosys_mobile.xcodeproj")
      # build_app(scheme: "silosys_mobile", workspace: "silosys_mobile.xcworkspace")
      firebase_app_distribution(
          app: ENV["FIREBASE_IOS_APP_ID"],
          testers_file: "../../testers.txt",
          release_notes_file: "../../release-notes.txt",
          firebase_cli_token: ENV["FIREBASE_TOKEN"],
          debug: true
      )
  end
end

`./fastlane/Appfile`

# apple_id("[[APPLE_ID]]") # Your Apple email address

# For more information about the Appfile, see:
#     https://docs.fastlane.tools/advanced/#appfile
app_identifier("io.grainchain.silosys-mobile")

fastlane gems

Gem
Version
Update-Status

fastlane
2.187.0
✅ Up-To-Date

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-firebase_app_distribution
0.2.9
✅ Up-To-Date

Loaded gems

Gem
Version

did_you_mean
1.3.0

bundler
2.2.23

rake
13.0.6

CFPropertyList
3.0.3

public_suffix
4.0.6

addressable
2.8.0

artifactory
3.0.15

atomos
0.1.3

aws-eventstream
1.1.1

aws-partitions
1.478.0

aws-sigv4
1.2.4

jmespath
1.4.0

aws-sdk-core
3.117.0

aws-sdk-kms
1.44.0

aws-sdk-s3
1.96.1

babosa
1.0.4

claide
1.0.3

colored
1.2

colored2
3.1.2

highline
2.0.3

commander
4.6.0

declarative
0.0.20

digest-crc
0.6.3

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

dotenv
2.7.6

emoji_regex
3.2.2

excon
0.84.0

faraday-em_http
1.0.0

faraday-em_synchrony
1.0.0

faraday-excon
1.1.0

faraday-httpclient
1.0.1

faraday-net_http
1.0.1

faraday-net_http_persistent
1.2.0

faraday-patron
1.0.0

multipart-post
2.0.0

ruby2_keywords
0.0.4

faraday
1.5.1

http-cookie
1.0.4

faraday-cookie_jar
0.0.7

faraday_middleware
1.0.0

fastimage
2.2.4

gh_inspector
1.1.3

jwt
2.2.3

memoist
0.16.2

multi_json
1.15.0

os
1.1.1

signet
0.15.0

googleauth
0.16.2

httpclient
2.8.3

mini_mime
1.1.0

trailblazer-option
0.1.1

uber
0.1.0

representable
3.1.1

retriable
3.1.2

rexml
3.2.5

webrick
1.7.0

google-apis-core
0.4.0

google-apis-androidpublisher_v3
0.8.0

google-apis-playcustomapp_v1
0.5.0

google-apis-iamcredentials_v1
0.6.0

google-apis-storage_v1
0.6.0

google-cloud-env
1.5.0

google-cloud-errors
1.1.0

google-cloud-core
1.6.0

google-cloud-storage
1.34.1

json
2.5.1

mini_magick
4.11.0

naturally
2.2.1

plist
3.6.0

rubyzip
2.3.2

security
0.1.3

simctl
1.6.8

terminal-notifier
2.0.0

unicode-display_width
1.7.0

terminal-table
1.8.0

tty-screen
0.8.1

tty-cursor
0.7.1

tty-spinner
0.9.3

word_wrap
1.0.0

nanaimo
0.3.0

xcodeproj
1.20.0

rouge
2.0.7

xcpretty
0.3.0

xcpretty-travis-formatter
1.0.1

fastlane-plugin-firebase_app_distribution
0.2.9

generated on: 2021-07-14

Hi @RodrigoSosa95.
I've taken a look at the plugin's code and it seems that based on your fastfile, the plugin will know that you try to upload iOS app, but it will not know which ipa file should be uploaded.
If you uncomment build_app(scheme: "silosys_mobile", workspace: "silosys_mobile.xcworkspace") it should figure this out.
https://github.com/fastlane/fastlane-plugin-firebase_app_distribution/blob/2fb39170929323590b0877dcb5ac9cbf775a49a8/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb#L159-L162
Otherwise you need to use ipa_path parameter to point to binary if it's not in current directory:
https://github.com/fastlane/fastlane-plugin-firebase_app_distribution/blob/2fb39170929323590b0877dcb5ac9cbf775a49a8/lib/fastlane/plugin/firebase_app_distribution/actions/firebase_app_distribution_action.rb#L107-L112

Hi @RodrigoSosa95
If the above suggestion also will not work, then I will recommend you to open the issue in fastlane-plugin-firebase_app_distribution git repo, They can help us much faster and release a new plugin version if required.
https://github.com/fastlane/fastlane-plugin-firebase_app_distribution/issues


Starting development server ERROR: Migration...

When starting the server there is an error.
==> Starting the development server...  ERROR: Migration<PHONE_NUMBER>5752-create-users.js (or wrapper) didn't return a promise

Steps to reproduce the behavior:

Install npm vapid-cli package
Create a new project folder
vapid start . doesn't output anything and shows the error
==> Starting the development server...  ERROR: Migration<PHONE_NUMBER>5752-create-users.js (or wrapper) didn't return a promise

Environment

MacOS: 10.14.1
Node Version v10.13.0
Vapid Version<EMAIL_ADDRESS>
I've tried to look for this issue but did not see any bug or answers in the forum.

Me too

Same here. I followed the exact steps on the vapid home page.

Thanks for letting me know. I'll look into this today.

Just released v0.3.3, which should fix this problem. 🤞
To update: npm install -g vapid-cli
Let me know if that does/doesn't work.

Can confirm that's working after the fix.


I wonder if the graph is high contrast enough for high contrast themes

Testing #217398

I'm not actually sure... but it feels not.
cc @daviddossett

@lszomoru maybe you can reuse focusBorder and contrastBorder for at least some of these? Better yet, used dashed and/or dotted lines since it will be so hard to distinguish between colors in the first place.

Thanks @daviddossett. I would love to work with you or @hbons next milestone to create a color palette that would be used for the various swim lanes of the graph.

I'd suggest starting with those two colors for the first two levels in hc-light and hc-dark themes and we can see how it feels. Maybe from there we just alternate between the two and then start using different stroke patterns for nth-of-type(3), and so on.
It's unlikely that we will have many color options in an HC context that will actually have enough meaningful contrast between themselves.


New release (0.14)?

Even though there was a release 0.13 not so long ago (and some dev releases since), it seems like a lot of really cool and useful features were added right afterwards (most notably the PEP440 improvements). IMHO these seem worthy of a version up tick. Thoughts?

+1
We are forced to use pip<1.6 because of compatibility issues with PEP440 of versioneer'ed projects.

PEP 440 compatibility is definitely a big deal. As a workaround, you can pip install the latest master: pip install git+https://github.com/warner/python-versioneer.git
That will install it as version "0.13-dev". From there follow the "Updating Versioneer" instructions as if it's a normal upgrade. I don't normally recommend doing this but I think Versioneer is a special-case dependency since it gets embedded directly in your project, and you can just upgrade it from PyPI when 0.14 gets pushed.

Cool, I'll make an 0.14 now. I've been pushing on the "style" branch (a new approach to the "template" branch, to let you pick which version style you want), but I got stuck on it. So yeah, a 0.14 with just the main PEP440 "TAG+DISTANCE" -style version strings is a good idea.
(Note that the corner cases may change between this 0.14 and whatever comes out next, as I figure out the "style" branch implementation: things like what version string to show when there are no tags at all).

@warner That sounds interesting. I don't mean to force your hand. If you feel it's not ready yet, that's fine. Just thought, you had some cool things that merited a release. :)
@richardotis Thanks for sharing. That's what I have done.

Done, 0.14 is on pypi. Lemme know if you run into any problems.

Thanks.

Looks good so far. :)


work on mirror functionality / oci mirror [skip ci]

This is the start of the "mirror" implemnetation that would

be able to handle multiple mirrors of a single channel
reroute a channel to an "internal" mirror (for on-prem deployments)
handle OCI channels to pull data from

Looks like some pushed artifacts have the wrong mediaType / no mediaType: pthread-stubs (https://github.com/orgs/channel-mirrors/packages/container/conda-forge%2Fosx-arm64%2Fpthread-stubs/23610821?tag=0.4-h27ca646_1001)

TODOs:

sort channel keys from long to short, so that both https://conda.anaconda.org and more specific https://conda.anaconda.org/conda-forge work.
add a "manifest" cache for OCI mirrors in order to only download the manifest once (instead of three times for checking jlap, zstd and bz2 existence (this one is deferred)
fix issues on the actual OCI registry

I think for this PR we shoudl fix the first item, but defer the other ones (and fix them in a little while when the OCI registry itself is fully functional).

What will the pixi lockfile look like then?
Currently, it looks like this:
version: 4
environments:
  default:
    channels:
    - url: https://conda.anaconda.org/conda-forge/
    packages:
      linux-64:
      - conda: https://conda.anaconda.org/conda-forge/linux-64/_libgcc_mutex-0.1-conda_forge.tar.bz2
      - conda: https://conda.anaconda.org/conda-forge/linux-64/_openmp_mutex-4.5-2_gnu.tar.bz2
      - conda: https://conda.anaconda.org/conda-forge/linux-64/backports.zoneinfo-0.2.1-py312h7900ff3_8.conda
      - conda: https://conda.anaconda.org/conda-forge/linux-64/bzip2-1.0.8-hd590300_5.conda
      - conda: https://conda.anaconda.org/conda-forge/linux-64/ca-certificates-2023.11.17-hbcca054_0.conda
      - conda: https://conda.anaconda.org/conda-forge/linux-64/ld_impl_linux-64-2.40-h41732ed_0.conda

When we have multiple mirrors or even URL rewrites, will you still use this format or instead only display the channel name
and platform but not the URL?


RFE and Docup - needs a way to break out of loop

It would be nice to show in the documentation how one could break out of the loop and/or cancel a loop with an incoming message.
also in the 'Usage' section you have a spelling error
Usage
Example flow is in examples/exmple.json.  <===== missing 'a' in exmple.json
Drag & drop in your Node-RED editor.

I guess the OP - and me - would like to have a way to programmatically break out the while loop (before the condition is met).

I should have said that there shoud be a programatic way to break out of a loop.
Lets say I set the node to loop 1000 times (for whatever reason) and a new event comes into the flow and I need to get out of the loop. It would be nice if I could send a msg with a msg.break or msg.reset or msg.payload set to 'break' that would stop/break out of the loop similar how you can in a switch statement, for or while loop


Add tcnksm/ghr

https://github.com/tcnksm/ghr
Upload multiple artifacts to GitHub Release in parallel

#86 tcnksm/ghr

https://github.com/tcnksm/ghr
Upload multiple artifacts to GitHub Release in parallel


Decide what Stock should be include in our project.

We'll only use

AAPL/USD
IBM/USD
JPM/USD
MSFT/USD
NKE/USD
TSLAA/USD

for now.


Storage account clarification

There should be a note to create the storage account name with 15 or fewer characters, otherwise the script used in https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable will fail due to AD DS naming requirements.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3b190fd1-42f6-3a90-5931-74b2ccd309c3
Version Independent ID: c4ca3c86-6257-59dd-e5a3-d40d4e0fa83c
Content: Create an Azure Files file share with a domain controller - Azure
Content Source: articles/virtual-desktop/create-file-share.md
Service: virtual-desktop
GitHub Login: @Heidilohr
Microsoft Alias: helohr

@bschlechty Thanks for your comment. We will review the issue and get back to you shortly.

@bschlechty Can you please share the document with this information on naming restriction you shared?
Are you referring to the Domain Prefix restrictions as described here?

Domain prefix restrictions: You can't create a managed domain with a prefix longer than 15 characters. The prefix of your specified domain name (such as aaddscontoso in the aaddscontoso.com domain name) must contain 15 or fewer characters.

We will now close this issue. Please share the details as requested above when you are ready and tag me in a comment. I will reopen it and we will gladly continue the discussion. Thanks :)


Cancelling builds has no effect on one of my pipelines

Agent Version and Platform
Version of your agent? 2.155.1
OS of the machine running the agent? OSX and Linux
Azure DevOps Type and Version
dev.azure.com (formerly visualstudio.com) or on-premises TFS/Azure DevOps Server?
If dev.azure.com, what is your organization name? https://dev.azure.com/alecmocatta
What's not working?
The "Cancel" button has no effect on one of my pipelines.
For example, I clicked "Cancel" for this build and it's still building: https://dev.azure.com/alecmocatta/constellation/_build/results?buildId=469
I clicked "Cancel" for this build, and it continued building for another 2 hours: https://dev.azure.com/alecmocatta/constellation/_build/results?buildId=464
Agent and Worker's Diagnostic Logs
Do I get this with "Queue with diagnostics"? If so I'll update this issue with it shortly.

Cross-posted https://developercommunity.visualstudio.com/content/problem/735409/cancelling-a-build-doesnt-work.html


[Feat] No proper spacing between the icon and word shopping in the blog section.

Description
Proper spacing is required between the icon and the words.
Screenshots

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I'm a GSSoC'24-Extd contributor
[X] I am willing to work on this issue (optional)
[X] I'm a Hacktoberfest'24 contributor

@TanishSen @TanishSen, everything looks good. Please check again and raise an issue accordingly, which I’ll be happy to assign to you. Thank you!

please ⭐ our repo

Join our official Discord server & discuss about new features and bugs raise issue & PR accordingly.

And also follow us on Linkedin


Do not use the image 1.18-alpine3.13 because it's not available

Two remarks:

Please do not always update to the latest patch version
Please use the image version 1.18-alpine, so it won't happen again that a version is not available anymore

I updated the autoupdate-service, the icc-service and the vote-service. The first both repos already had an github action that tested the build of the dockerfile. And the vote-service was the only one that used a point-release of the base image...


HotReload Takes minutes to process when updating a CSHTML file.

Describe the bug:
HotReload takes minutes to process when updating a CSHTML file.
Version used:
VS2022 17.0 Preview 2 - Been happening since VS2022 17.0 Release
Steps to reproduce the behavior:

Open a CSHTML view
Change some text
Click Save (Which Triggers HotReload)
Wait 1-5 minutes
Page Reloads.

Expected behavior:
Like it use to be in VS2017 - Save the CSHTML and then refresh the browser and see the instant change.
Actual behavior:
Slow - Quicker to close and restart/rebuild the application.
https://user-images.githubusercontent.com/17169917/149862406-67fc3605-a4ac-41f1-88f9-59ea553d1328.mp4

@KonnectSalon to clarify are you saying this is happening for 17.1-Preview2 for you? Also, would you mind clarifying the following:

Do you have the legacy Razor editor enabled?
Are you in a .NET Core web application ( I'm pretty sure you are based off your usage of @Localizer but wanted to check) ?

Do you have the legacy Razor editor enabled?
I do now however the same thing happens.

Are you in a .NET Core web application ( I'm pretty sure you are based off your usage of @Localizer but wanted to check) ?
Yes .NET core web app under .net 6.0.1

@KonnectSalon thanks for clarifying. Going to move this over to aspnetcore to allow the Razor sourcegenerator folks to take first stab.


Show element binding expressions in the sidebar panel alongside scope properties

This pull request modifies the AngularJS Properties sidebar panel in two ways:

Moves existing properties into a scope key on the panel object
Creates a bindings array property that will contain any binding expressions associated with the element

Knowing the binding expressions can be useful in certain circumstances, such as when creating protractor e2e tests.

This looks very useful, do you mind bringing it up to date?

No response, closing.


NOTICK: adjust timeouts for e2e tests at Jenkins level

Ensure test stage has adequate time to complete (20 min max) and up overall time

@JamesHR3  FYI


Prevent loading twice

Hi, is there a way to check if it's already been loaded? I'm using the unslick before closing a template but in some cases it still remains without being destroyed and giving an error when re-rendering the template.

Sure, check out the events. Hope that helps.


How to change current open files ?

Description
Every time I open code-server, it always opens several fix files : package.json, ide.conf and so on. I just want the code-server to remember which files I left open when closing the browser tab and open them when I use code-server again.
I've tried the following but doesn't work:

fresh the page
reboot the server

Related Issues

Duplicate of #801. This should be fixed pretty soon (as part of our v2).


KOGITO-3181 - add trusty ui scorecard/controller/tests

jira: https://issues.redhat.com/browse/KOGITO-3181
This PR aims to add the trusty UI to the operator. The Trusty UI will communicate with the trusty service so to retrieve the information that will be displayed to the user.
Many thanks for submiting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors' guide
[x] Pull Request title is properly formatted: [KOGITO-XYZ] Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket
[x] Your feature/bug fix has a unit test that verifies it
[] You've tested the new feature/bug fix in an actual OpenShift cluster

depends on https://github.com/kiegroup/kogito-images/pull/227

/jenkins test

/jenkins test

@r00ta Lints are failing.

/jenkins test

/jenkins test

/jenkins test

/jenkins test

/jenkins test

/jenkins test

/jenkins test

Hi @ricardozanini @spolti and others, apparently the CI is broken (in all the PRs the errors are the same)

The code looks ok, will check test.

Few comments in test, otherwise looks good.

Triggering GH Actions once more, codecov is not being a good guy.

/jenkins test

Hi, apparently the bdd test of the PR is successful
{"level":"info","T":"2020-09-12T16:02:36.389Z","logger":"jenkins-cucumber-a8f8","msg":"'trusty-ui running' is successful"}
{"level":"info","T":"2020-09-12T16:02:36.391Z","logger":"jenkins-cucumber-a8f8","msg":"Step HTTP GET request on service \"trusty-ui\" with path \"\" is successful within 2 minutes"}
{"level":"info","T":"2020-09-12T16:02:36.396Z","logger":"jenkins-cucumber-a8f8","msg":"Wait 6m0s for Route trusty-ui available"}
{"level":"info","T":"2020-09-12T16:02:37.412Z","logger":"jenkins-cucumber-a8f8","msg":"'Route trusty-ui available' is successful"}
{"level":"info","T":"2020-09-12T16:02:37.424Z","logger":"jenkins-cucumber-a8f8","msg":"Wait 6m0s for HTTP GET request on path '' to be successful"}
{"level":"info","T":"2020-09-12T16:02:38.507Z","logger":"jenkins-cucumber-a8f8","msg":"'HTTP GET request on path '' to be successful' is successful"}
{"level":"info","T":"2020-09-12T16:02:38.606Z","logger":"jenkins-cucumber-a8f8","msg":"Successful scenario 'Install Kogito Trusty UI'"}
{"level":"info","T":"2020-09-12T16:02:38.606Z","logger":"jenkins-cucumber-a8f8","msg":"Scenario duration: 1m9.107993829s"}
{"level":"info","T":"2020-09-12T16:02:38.613Z","logger":"jenkins-cucumber-a8f8","msg":"Delete created namespace jenkins-cucumber-a8f8"}
{"level":"info","T":"2020-09-12T16:02:38.614Z","logger":"jenkins-cucumber-a8f8","msg":"Delete namespace jenkins-cucumber-a8f8"}

@sutaakar have you verified this PR? After @spolti check, can we merge it?

Waiting for #558 to finish

/jenkins test

Well, the UI seems to work (it shows list of cases in case it is connected to trusty service, although clicking on a case shows empty page. Not sure if it is a bug or feature not yet implemented or I have misconfigured something)
@r00ta Is the trusty UI intended to be used together with explainability service or is it intended to work independently with optional dependency on explainability?
Also, is there some REST endpoint exposing results of the Trusty UI? I suppose there isn't any but better to ask. Without such endpoint we can just check in the test that UI responds with some HTTP code but we cannot check what is actually available there. That would have to be done using UI testing.
Side note - for usage in cloud user has to specify KOGITO_TRUSTY_ENDPOINT env variable to be able to define URL of Trusty to connect to. This should be reflected in docs and CLI help.
Current text: You won't be able to use the Trusty UI if Trusty is not deployed in the same project either using Kogito CLI or the Kogito Operator is a bit misleading.

/jenkins test

Keycloak errors, not related:
 <testsuite name="Kogito integration with Keycloak" tests="2" skipped="0" failures="2" errors="0" time="1349.232662224">

    <testcase name="Install Kogito Data Index with Keycloak security" status="failed" time="1275.210407477">

      <failure message="Step Keycloak instance with realm "kogito-realm" and client "kogito-dataindex-service" is deployed: Timeout waiting for Pods with label name 'app' and value 'keycloak' available and running"></failure>

      <error message="Step Keycloak user "my-user" with password "my-password" is deployed" type="skipped"></error>

      <error message="Step Install Kogito Data Index with 1 replicas with configuration:" type="skipped"></error>

      <error message="Step Kogito Data Index has 1 pods running within 10 minutes" type="skipped"></error>

      <error message="Step Stores access token for user "my-user" and password "my-password" on realm "kogito-realm" and client "kogito-dataindex-service" into variable "my-user-token"" type="skipped"></error>

      <error message="Step GraphQL request on service "data-index" is successful using access token "{my-user-token}" within 2 minutes with path "graphql" and query:" type="skipped"></error>

    </testcase>

    <testcase name="Install Kogito Jobs Service with Keycloak security" status="failed" time="1349.207879401">

      <failure message="Step Keycloak instance with realm "kogito-realm" and client "kogito-jobs-service" is deployed: Timeout waiting for Pods with label name 'app' and value 'keycloak' available and running"></failure>

      <error message="Step Keycloak user "my-user" with password "my-password" is deployed" type="skipped"></error>

      <error message="Step Install Kogito Jobs Service with 1 replicas with configuration:" type="skipped"></error>

      <error message="Step Kogito Jobs Service has 1 pods running within 10 minutes" type="skipped"></error>

      <error message="Step HTTP GET request on service "jobs-service" with path "jobs" is forbidden within 1 minutes" type="skipped"></error>

      <error message="Step Stores access token for user "my-user" and password "my-password" on realm "kogito-realm" and client "kogito-jobs-service" into variable "my-user-token"" type="skipped"></error>

      <error message="Step HTTP POST request on service "jobs-service" using access token "{my-user-token}" is successful within 2 minutes with path "jobs" and body:" type="skipped"></error>

      <error message="Step HTTP GET request on service "jobs-service" using access token "{my-user-token}" with path "jobs/1" is successful within 1 minutes" type="skipped"></error>

    </testcase>

  </testsuite>

@r00ta as soon as you address @sutaakar I think we can merge.

Well, the UI seems to work (it shows list of cases in case it is connected to trusty service, although clicking on a case shows empty page. Not sure if it is a bug or feature not yet implemented or I have misconfigured something)
@r00ta Is the trusty UI intended to be used together with explainability service or is it intended to work independently with optional dependency on explainability?
Also, is there some REST endpoint exposing results of the Trusty UI? I suppose there isn't any but better to ask. Without such endpoint we can just check in the test that UI responds with some HTTP code but we cannot check what is actually available there. That would have to be done using UI testing.
Side note - for usage in cloud user has to specify KOGITO_TRUSTY_ENDPOINT env variable to be able to define URL of Trusty to connect to. This should be reflected in docs and CLI help.
Current text: You won't be able to use the Trusty UI if Trusty is not deployed in the same project either using Kogito CLI or the Kogito Operator is a bit misleading.

Hi @sutaakar , the TrustyUI (the frontend app) is intented to be paired with the Trusty service (backend app). At the moment we just check that the application is deployed, my assumption is that the backend and the frontend are already tested in the respective projects. We can implement some integration tests for the environmnent variable, I'll create a ticket for that as soon as jira is working again (it's down atm).
The TrustyUI exposes many endpoints where the user can fetch html+js pages. The concept and the implementation is very similar to the management console.

@sutaakar let me know if we are ready.

@r00ta Thanks
@ricardozanini good for me now


Add character sets: Arabic, Greek, Hebrew, Japanese, Thai, Korean

This change adds support for the following character sets:

ISO-IR 13 (Japanese)
ISO-IR 87 (Japanese multi-byte)
ISO-IR 126 (Greek)
ISO_IR 127 (Arabic)
ISO_IR 138 (Hebrew)
ISO-IR 149 (Korean)
ISO-IR 166 (Thai)

This is related to issue: #40, and is a superset of the currently open PR #444.
The full set of DICOM supported character sets is listed in: Table D.6.2-1. Supported Specific Character Set Defined Terms.  This change covers the character sets in this list which are also supported by rust-encoding.
It appears that rust-encoding does not include support for ISO-IR 148 (Latin 5) or ISO-IR 159 (Japanese supplementary characters), so these have not been included.

Thank you for your pull request! Do you happen to know whether any of these encodings also have an implementation at encoding_rs? We fear that we may end up stuck with rust-encoding, which is no longer maintained (#200).

The full set of DICOM supported character sets is listed in: Table D.6.2-1. Supported Specific Character Set Defined Terms.

A curious reference. The normative part of the standard would be in PS3.5 section 6.1, though I agree that the latest revisions do not expose the available character sets as nicely as in that table.

Based on a review of the encoding_rs_compat library, all of the new character sets are compatible with encoding_rs (see: compat.rs.  So I don't think that this change will be a blocker to switching.
Yeah, I just found the SpecificCharacterSet "defined terms" table easier to work from.

Thanks Eduardo!  Appreciate your quick responses.


Request for second view of timeline JSON's - old school tabular.

Some who have weighed in on http://its-airborne.org/ have asked for a second representation of the same timeline data:  regular tables.
That's be a different page but consuming the same /media/ resource.  Timelines are one thing, but some non-techniocal perusers want to be able to quickly see whether something is in there or not. Perhaps with find-in-page instead of clicking Next> a bunch of times to move the timeline.

@paul-hammant not sure if it would be in scope of this template (as you know I haven't had a chance to do anything with it for like a year...), but pretty easy to add to a site. I use DataTables in other projects, which adds search, sort, and export, etc. If you are using the CSV option, Jekyll can easily generate a variety of different data outputs from the same source to be consumed by stuff other than TimelineJS.
You could:

add the data to the page as HTML and let DataTables initiate on that table
create some JSON that DataTables can consume (this is better for large sets)
write some JS that parses the timelinejs json to provide to DataTables (which would support external json data sources)

For example, see this collectionbuilder-gh table page, which is generated from this js include.
Another example, I parse a google sheet spreadsheet and create a table in this template, https://github.com/evanwill/table-sheet-test

Thanks - was fairly easy - https://github.com/its-airborne/timelines-site/blob/main/pages/historical-list.md

If you want to clean it up a bit, you can use the "custom foot" option:
basically move the JS bit into an include, such as "_includes/historic-table.html", then on the markdown stub, use front matter foot: historic-table.html. On page build, this will put your custom JS at the bottom of the page, after the template's JQuery and bootstrap is loaded (so you don't have to load jquery twice), making things a bit more efficient on your site.


Test Request: Kong Gateway [OSS|EE] version <IP_ADDRESS>-rc.5

What component needs testing with KIC?
Kong Gateway EE
Container image
kong/kong-gateway-dev:<IP_ADDRESS>-rc.5
Additional information
No response

https://github.com/Kong/kubernetes-ingress-controller/issues/6809 TestConsumerGroup failed for scenario enterpise-postgres. Please take a look if anything changed on processing consumer groups.


stable/prometheus-operator - updated location/name of the manifest files used for CRDs in promethe…

updated file names for CRDs used in prometheus operator, they have been updated on coreos/prometheus-operator repository.
https://github.com/coreos/prometheus-operator/tree/master/example/prometheus-operator-crd

What this PR does / why we need it:
This PR updates the location/name of the CRDs used in prometheus-operator, the name of the files on the coreos/prometheus-operator repository has changed and the location specified in the current README is returning not found (404) error.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[ x] DCO signed
[ x] Title of the PR starts with chart name (e.g. [stable/mychartname])

Looks like the latest CRDs aren't safe to use right now. There's a pull request open for linking these to a specific version.
I also suggest you don't use this workaround but instead upgrade to a version of helm that fixes CRD provisioning

I see, thanks.


feat: add support for go

This only includes 2 types I could find to split on, so it's not exhaustive, but a lot of literal types in go use the same syntax, so it should cover a lot.
As a side note, when I tried testing this out in my config by just adding the go table, I kept getting filetype not supported errors. So I'm not sure adding in your own overrides works currently  but tbh I didn't check exhaustively as I don't have too much time to hand atm

Awesome, thanks! I indeed could reproduce the bug you mentioned and think is should be fixed by #5


Debian glibc 2.12 dependency problem

I have a few machines that still are using debian squeeze (sic!) and i am running sensu-clients on them.
Until version 0.23.2-1 of the debian package everything worked fine, but from version 0.23.2-2 on, the client cannot start because of glibc dependency problems:
Starting sensu-client:/opt/sensu/embedded/bin/ruby: /lib/libpthread.so.0: version `GLIBC_2.12' not found (required by /opt/sensu/embedded/lib/libruby.so.2.3)
failed!
Was this on purpose? Was the ruby version changed in between the two builds (and all the following)?
How are the debian packages build? I assume by this dockerfile here: https://github.com/sensu/sensu-build/blob/master/dockerfiles/debian-i386 ? So i could see if i can build my own packages...

Hi @kosli,
This happened as a result of moving from full-blown VMs to Dockerfiles in our build pipeline. As Debian Squeeze was EOL'd in February 2016 we do not plan to address the issue you have raised.
The dockerfile you have linked to is the container used for Debian i386 builds. As a note, Sensu 0.27 and forward will be built using https://github.com/sensu/sensu-omnibus instead of sensu-build.
We plan to release a list of supported platforms in the near future.
#monitoringlove


Add the ownership holder to separate the logic of ownership and conta…

…iner.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Update Readme

Update with:

[ ] Features
[ ] Technologies used
[ ] Quick start
[ ] Rules & Standards

Added new Item to checklist Rules & Standards


GAPIC Header Consistency: Vision

@daspecster Would you please take a longer look at this one? I found the "two clients" thing really confusing and am not sure I did this correctly.
In particular, I am pretty sure the existing code threw away the credentials argument when being used with GAX. (Not sure how anyone would successfully set any of the other arguments, either.) I updated this and added a test for it.

Taking a look now.

@daspecster Please verify now. (Also, obviously, waiting on tests.)

Pending travis/circle this LGTM.  I would recommend running the system tests as well if you haven't yet.

The Travis errors suggest the credentials are not being passed correctly.

@lukesneeringer cool looks like that worked. Just a lint issue now.


Exposure check is not automatically performed in the background

Description
This issue has been observed on two different devices, both running the latest Stopp Corona App and iOS version.
The Stopp Corona app version 2.0.4 was installed and setup last Friday on both devices.
After the initial setup and granting the Exposure Logging permission, the app was sent to the background and not opened again for a couple of days.
Fast forward a few days: After 1 week of usage, navigating to "Settings > Privacy > Health > COVID-19 Exposure Logging > Exposure Checks" showed 0 Exposure Checks in the last 14 days on both devices.
Only after re-opening the Stopp Corona app, the first Exposure Check appeared in Settings.
Now (after  re-opening the app), I can observe an automatic exposure check performed in the background every ~2 hours.
It seems like the app does not automatically perform the exposure check after the initial setup and does not perform any subsequent automatic exposure checks in the background. The app needs to be opened again after a few days, to enable the desired automatic background exposure check.
Reproduction steps

Download and install Stopp Corona 2.0.4 on a new iOS device
Open the app, grant the Exposure Logging permission
Send the app to the background
Wait a few days without opening the app
Observe, that "Settings > Privacy > Health > COVID-19 Exposure Logging > Exposure Checks" shows 0 Exposure Checks in the last 14 days

Additional information
Devices: iPhone XR (iOS 13.5.1), iPhone Xs (iOS 13.5.1)
Stopp Corona 2.0.4

After 1 week of usage
After re-opening the app

What did you expect
The Stopp Corona app should automatically perform regular exposure checks in the background, without the need to open the app at any point after the initial setup.

I have a similar experience. Running the app on iOS and Android both phones are always with me. Android version found 7 contacts in 2 days and iOS zero. It should at least find his 'neighbour' Android device.

The issue is not related to the collection of keys from other devices, this seems to work. In my case, the exposure check was never automatically performed in the background until the app was manually opened again.
As soon as the exposure check runs, it reports >1000 found keys.

We are currently investigating why the background task is not always triggered correctly and we are in contact with apple regarding this issue.
The 2.0.4 version was released during this week, so I guess you had a previous version installed last friday.

Dear developers,
i observed the same issue that @aschuch described in the original post on my device, running iOS 13.5.1 on an iPhone SE (2020). Same with 2.0.4: Startet Stopp Corona manually on Saturday 12:07. Then 5 exposure check were made in background (approx. every 2 hours; 22:56 the last). Yesterday nothing. Today started Stopp Corona manually and after a few seconds "Exposure Checks" list shows a new entry.

Same issue here. I have some exposure checks, but sometimes when I'm with colleagues in the same room I have no key pair exchanged...

The issue is not related to the collection of keys from other devices, this seems to work. In my case, the exposure check was never automatically performed in the background until the app was manually opened again.
As soon as the exposure check runs, it reports >1000 found keys.

Im not sure whats the correct meaning of the field "Anzahl der bereitgestellten Schlüssel" because I also have numbers between 1000 and 1100 there but I never ever had so many contacts (or exchanged keys). The next thing which is weird is, that the number is not continuously incrementing from check to check.

Same issue here. I have some exposure checks, but sometimes when I'm with colleagues in the same room I have no key pair exchanged...

The issue is not related to the collection of keys from other devices, this seems to work. In my case, the exposure check was never automatically performed in the background until the app was manually opened again.
As soon as the exposure check runs, it reports >1000 found keys.
...

Im not sure whats the correct meaning of the field "Anzahl der bereitgestellten Schlüssel" because I also have numbers between 1000 and 1100 there but I never ever had so many contacts (or exchanged keys). The next thing which is weird is, that the number is not continuously incrementing from check to check.

As far i understood is that the value "Anzahl der bereitgestellten Schlüssel" means the downloaded keys (plus some dummies) from the application servers of possible COVID-19 diseased people. I have some similar numbers on my phone. The value "Anzahl der abgeglichenen Schlüssel" are the number of keys stored on your device matching the downloaded keys. If this number is greater than 0 you might have contact with someone COVID-19 positive.

I think there is a fixed number of random keys added to the reports for privacy reasons ( and I think it is 1000 ).
Depending on how many keys were uploaded or revoked the last days the number will go up and down ..

So I cant see that my phone has exchanged keys with another phone anywhere. Neither in the StoppCorona-App or in the Privacy-Health-Covid19 Exposure Settings?
The Log I see in the Settings is only the check with the central server where all the positive results are stored?

So I cant see that my phone has exchanged keys with another phone anywhere. Neither in the StoppCorona-App or in the Privacy-Health-Covid19 Exposure Settings?
True
The Log I see in the Settings is only the check with the central server where all the positive results are stored?
Yes

Is there any chance for the developer to get the information how many keys are exchanged by the app or is it because of privacy held secretly?
Is it better to say that the keys are exchanged by the iOS&Android Service/BT-Interface and the app only controls all this stuff (sending frequency, renewal of keys and so on) with the new API.

No.. the api is very restricted. There is no way for the app to find out how many people you meet or stuff like that. Only when the key of the other person is downloaded over the api the the app can get some details about those contacts. The api is very restricted, it can be only called 15 times per day for example and the phone will always inform you with a push message when the app checks details about those possible exposures.

2.0.5 has been reviewed by apple and should show up in the appstore soon.

Thanks, the update seems to resolve the issue.
The app had to be opened one more time after installing 2.0.5. Now, regular exposure checks are performed in the background automatically as expected.

It still doesnt work reliable. I have 2.0.5, iOS 13.5.1.
Today is 14.07.2020, the last check was performed on 11.07.2020 (see screenshot)
When I open the app, i get a new entry

Same here, my last check was on the 9th of July, since then no check. Today i started the App now i have two checks today

when did you update to 2.0.5 and did you open the app after the update?

Yes, i opened the App (at least i think so)

I updated immediately after your post here, after the update i think i opened the App. Since then i didnt open it again till today.

Same for me. Unreliable background. Updated to latest version on 9th of July. Started the App once. After that exposure checks were done in background until 12 th of July 07:31. Started again the app yesterday (the 13 th) and immediately afterwards an exposure check was made. Periodically every approx. 2 hours (with pause during the night; maybe because i'm going to flight mode) until today. Not a bis issue for me as i can have a look at that...

Just checked on an other iPhone: same behavior.

This issue is still occurring.

The issue is now back on my devices as well.
I did not open the app for quite a while and the last exposure check was performed on July 14th (over one week ago).

I've installed iOS 13.6 on 15.7. opened stop corona once after that and never again to see what's happening.
It looks like it is performing the checks every day now. Maybe the iOS Update fixed some things?
But the last 3 days look somewhat strange.

Unfortunately I haven’t been able to investigate this with my limited abilities to test this. I’m generally not sure how to do or review meaningful changes as there is no good system in place to ensure it does not regress in other ways.

I'm currently testing a version with small adjustments running on iOS 13.7, running the exposure checks fine 5-6 times a day without opening the app for over a week, so it looks like the problem is solved.
The version is currently going though internal QA.
It's important to update devices to 13.7. Many bugfixes and improvements were done to exposure framework.

Exposure checks work with app version 2.0.7 and iOS 14.1 on my device now.

I'm closing this bug for now .. if you experience any problems please let us know.


support line spacing by multiple

updateTextPropsOptions
interface TextPropsOptions {
	/**
	 * line spacing by pt. e.g.: 28 means 28pt
	 */
	lineSpacing?: number
	/**
	 * line spacing by multiple. e.g.: 1.2
	 */
	lineSpacingMultiple?: number
}

Thanks @wangfengming !


QCPortal:get_records() raises KeyError unless method, keywords, and basis are included

Describe the bug
qcportal: The collection function get_records() raises a KeyError unless method, keywords, and basis are included in the function call.  The function only requires one positional argument 'method' but truly requires 3 to return anything other than a KeyError  You can see more clearly the following 3 examples.
To Reproduce

>>> bdimer.get_records()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: get_records() missing 1 required positional argument: 'method'

1.
>>> bdimer.get_records(method='dft')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/adrian/projects/QCPortal/qcportal/collections/dataset.py", line 1554, in get_records
    raise KeyError(f"Requested query ({name}) did not match a known record.")
KeyError: 'Requested query (DFT) did not match a known record.'

>>> bdimer.get_records(method='dft',keywords='b3lyp')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/adrian/projects/QCPortal/qcportal/collections/dataset.py", line 1554, in get_records
    raise KeyError(f"Requested query ({name}) did not match a known record.")
KeyError: 'Requested query (DFT-b3lyp) did not match a known record.'

>>> bdimer.get_records(method='dft',basis='sto-3g')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/adrian/projects/QCPortal/qcportal/collections/dataset.py", line 1554, in get_records
    raise KeyError(f"Requested query ({name}) did not match a known record.")
KeyError: 'Requested query (DFT/sto-3g) did not match a known record.'

>>> bdimer.get_records(method='dft',keywords='b3lyp',basis='sto-3g')
        record
index
Sdimer    None
PDdimer   None
Tdimer    None
TTdimer   None

Expected behavior
In 1. I would expect get_records() to return all records using method='dft'.
In 2. I would expect get_records() to include all records using method='dft' and keyword='b3lyp'
In 3. I would expect get_records() to include all records using method='dft' and basis='sto-3g'
Additional context

Here is what get_values() and list_records() returns which maybe of use.

bdimer.get_values()

        DFT/sto-3g-b3lyp-d3 DFT/sto-3g-b3lyp DFT/6-31g-b3lyp
Sdimer                  NaN              NaN             NaN
PDdimer                 NaN              NaN             NaN
Tdimer                  NaN              NaN             NaN
TTdimer                 NaN              NaN             NaN
>>> bdimer.list_records()
   driver program method   basis  keywords                 name
0  energy  nwchem    dft  sto-3g  b3lyp-d3  DFT/sto-3g-b3lyp-d3
1  energy  nwchem    dft  sto-3g     b3lyp     DFT/sto-3g-b3lyp
2  energy  nwchem    dft   6-31g     b3lyp      DFT/6-31g-b3lyp

Thank you for this report!

@mattwelborn Do you think this will be quick? Might be nice to squeeze in as well.


Rethinking Nested Elements

Now that we are spending time rethinking how Selector Builder works, and now that we are focusing on performance for remote execution and minimizing wire calls....
I think we should investigate merging nested elements into a single locator when possible.
It woks as long as an element does not need filtering, so we create a locator for browser.tr.td like:
.//*[local-name()='tr']//[local-name()='td']

This would drop a number of current wire calls as we do our location recursion.
I'm not sure how this would affect other Selector implementations like Watizzle, etc.

I'm all for performance gains.
Note that when joining the selectors, it's a bit more complicated that just concatenating them. We will need to make sure that we are only searching within the first matching element. For example, the mentioned XPath will actually look for all tds that are a descendant of any tr. In contrast, the Watir code would only look for tds within the very first tr.

But we'd be finding the first td in the first tr.
In other words, the example above will work, but this won't:
browser.tr.tds

I'm not sure off hand how we would support that.
We could also support Collections as query scopes with the XPath above:
browser.trs.td(class: 'foo')

I'm saying that given the HTML:

Then the Watir code:
p browser.tr.td.exists?
#=> false

Is not equivalent to the suggested XPath:
p browser.td(xpath: ".//*[local-name()='tr']//*[local-name()='td']").exists?
#=> true

In terms of collections, I think I am thinking the opposite. browser.tr.tds should be do-able. It's just a difference between matching first vs all. browser.trs.td would seem out-of-place given the current behaviour. It'd be a short-cut for browser.trs { |tr| tr.td }? I guess that's handy... but feels less readable?

Ah, I see what you are saying, yes, that makes sense.
I'd have to spend more time thinking about this and writing specs. Just wanted to put it on the radar as something that would be nice to see improved if we can find a way....
Could we just add an index to it to make it work?
.//*[local-name()='tr'][1]//*[local-name()='td']

That's what writing a bunch of specs is for...

#822 addresses this.


MBCn reordering (xclim.sdba.processing.reordering)

Setup Information

Xclim version:
Python version:
Operating System:

Context
Hello!
I've previously used MBCn via the MBC R package, and I was pouring through the xclim Statistical Downscaling and Bias-Adjustment notebook out of curiosity. As I was going through it I noticed something peculiar in the reordering/Restoring the Trend section.
Under the Restoring the Trend section, it states that "We reorder the result of the initial adjustment according to the rank structure of the NpdfT outputs to get our final bias-adjusted series", as also described in Alex Cannon's paper. In the subsequent function call however, it appears that the NpdfT output is being reordered using the rank structure of the initial adjustment as reference:
scenh = sdba.processing.reordering(hist, scenh, group="time")
As I understand, hist is the standardized initial QDM-adjusted variables, while scenh is the NpdfT adjusted historical output. In the function, ref=hist, and sim=scenh. Am I interpreting the syntax, or how the reordering is performed incorrectly?
Thanks!
Kenneth
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Oh! You are totally right, the arguments are indeed inverted...
The notebook should read:
scenh = sdba.processing.reordering(scenh, hist, group="time")
scens = sdba.processing.reordering(scens, sim, group="time")

Thanks a lot for notifying us! I'll fix the documentation asap.


Administrator login, CAS access callback

Dear restaf developers,
in my current projects, I've got issues with CAS data access as soon as I'm logged in as administrator.
How can I workaround that the CAS data does not arrive directly but a question related whether I'd like to access CAS as administrator is calling back and no data can be loaded? Actually in the relevant projects it would be great having the possibility to switch to administrator mode as data would be accessible this way only for administrators who are checking issues from users.

@michburger

When you logged on to Viya, did you answer  in the positive to a prompt similar to the picture below

This dialog might look different in your case based on how Viya was configured?

What is the prompt you see when the code tries to read a cas table?

Note: restaf itself is not aware of access rights. It assumed that the Viya API's will handle all such issues.

Dear devakumaraswamy,it is no visible prompt. The result of a cas query contains some query and restaf simply cannot proceed.Will send you the details tomorrow.Michael Michael Burger SoftMatch.net
-------- Ursprüngliche Nachricht --------Von: devakumaraswamy @.> Datum: 20.10.24  16:36  (GMT+01:00) An: sassoftware/restaf @.> Cc: Michael Burger @.>, Mention @.> Betreff: Re: [sassoftware/restaf] Administrator login, CAS access callback (Issue #119)
@michburger
When you logged on to Viya, did you answer  in the positive to a prompt similar to the picture below
image.png (view on web)
This dialog might look different in your case based on how Viya was configured?
What is the prompt you see when the code tries to read a cas table?
Note: restaf itself is not aware of access rights. It assumed that the Viya API's will handle all such issues.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Want to add a data point: If the table has access rights specified, the admin user does not have "super-power" to access the tables. This makes sense - since folks who do Viya administration are not usually permitted to see business data.

Seems that the issue got resolved with an update from SAS Viya ...
I mean if I'm logged on as administrator, there is no need for other ask back.

I could reproduce:
as administrator CAS is asking whether I'd like to elevate but using restaf I cannot answer:
{
"auth_request": {
"clientId": "sas.casControl",
"scope": [
"openid",
"uaa.user",
"SASAdministrators"
],
"requestParameters": {
"response_type": "code",
"redirect_uri": "/casManagement/",
"state": "dd5b4750-c990-4b4d-93a7-02101d053f12",
"client_id": "sas.casControl"
},
"approvalParameters": {},
"state": "dd5b4750-c990-4b4d-93a7-02101d053f12",
"responseTypes": [
"code"
],
"resourceIds": [
"sas.casControl",
"openid",
"uaa"
],
"authorities": [
{
"authority": "uaa.resource"
},
{
"authority": "sasapp"
}
],
"approved": false,
"redirectUri": "/casManagement/",
"extensions": {}
},
"approved_scopes": [],
"denied_scopes": [
{
"code": "scope.SASAdministrators",
"text": "SASAdministrators"
}
],
"options": {
"confirm": {
"path": "/SASLogon/oauth/authorize",
"location": "https://sdtb-viya-emea.siemens-healthineers.com/SASLogon/oauth/authorize",
"value": "true",
"key": "user_oauth_approval"
},
"deny": {
"path": "/SASLogon/oauth/authorize",
"location": "https://sdtb-viya-emea.siemens-healthineers.com/SASLogon/oauth/authorize",
"value": "false",
"key": "user_oauth_approval"
}
},
"redirect_uri": "/casManagement/",
"undecided_scopes": [],
"scopes": [
{
"code": "scope.SASAdministrators",
"text": "SASAdministrators"
}
],
"message": "To confirm or deny access POST to the following locations with the parameters requested.",
"client_display_name": "sas.casControl"
}

restaf.min.js:7  Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'map')
at restaf.min.js:7:38813
at e.a (restaf.min.js:7:39141)
at restaf.min.js:1:79106

@michburger  I do not quite follow your responses.

what did the updated Viya fix?
is the last message after the update? The error usually happens when the response from Viya is something that looks like ok to restaf but is not - so I am guessing the access is not working.
does it work if you logon as a user who is authorized to access the table?

@michburger
can you comment on my questions?
Want to make sure your issue is resolved.
Thanks...
Deva

Dear Deva,
unfortunately I was wrong: The issue is not fixed.
Typically, the problem shows up in Edge and in the Console I can find this output when working as Administrator in Viya:
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'map')
at restaf.min.js:7:38813
at e.a (restaf.min.js:7:39141)
at restaf.min.js:1:79106
The background: We've created a custom frontend as an IFrame / WebContent in the Viya report. That means, we're using the Viya login and host an additional web part inside.
That means, my administrator login is valid for restaf.
For this case, restaf seems not yet to be prepared:
            "/casManagement/" !== t.href && "/casManagement" !== t.href || "GET" !== t.method || (e.data.results.links = e.data.results.links.map((function(t) {
                return "collection" === t.rel && (t.title = "servers",
                t.rel = "servers",
                t.patch = "cas"),
                t
            }

The problem is with this check in the first line because in this situation the variables are set as:
t.method: "GET"
t.href: "/casManagement/"
e.status: 200
e.data.results.links is undefined - which causes the whole process to stop here.
the e.data.results object actually is a query related to admin access:
{
"auth_request": {
"clientId": "sas.casControl",
"scope": [
"openid",
"uaa.user",
"SASAdministrators"
],
"requestParameters": {
"response_type": "code",
"redirect_uri": "/casManagement/",
"state": "1b9a6562-95d1-48c6-a5df-2c75a4ff15d9",
"client_id": "sas.casControl"
},
"approvalParameters": {},
"state": "1b9a6562-95d1-48c6-a5df-2c75a4ff15d9",
"responseTypes": [
"code"
],
"resourceIds": [
"sas.casControl",
"openid",
"uaa"
],
"authorities": [
{
"authority": "uaa.resource"
},
{
"authority": "sasapp"
}
],
"approved": false,
"redirectUri": "/casManagement/",
"extensions": {}
},
"approved_scopes": [],
"denied_scopes": [
{
"code": "scope.SASAdministrators",
"text": "SASAdministrators"
}
],
"options": {
"confirm": {
"path": "/SASLogon/oauth/authorize",
"location": "https://sdtb-viya-emea.siemens-healthineers.com/SASLogon/oauth/authorize",
"value": "true",
"key": "user_oauth_approval"
},
"deny": {
"path": "/SASLogon/oauth/authorize",
"location": "https://sdtb-viya-emea.siemens-healthineers.com/SASLogon/oauth/authorize",
"value": "false",
"key": "user_oauth_approval"
}
},
"redirect_uri": "/casManagement/",
"undecided_scopes": [],
"scopes": [
{
"code": "scope.SASAdministrators",
"text": "SASAdministrators"
}
],
"message": "To confirm or deny access POST to the following locations with the parameters requested.",
"client_display_name": "sas.casControl"
}

@michburger
I and several folks run restaf based apps in webcontent.
You need to make sure that the logon information to restaf is set properly.
When running under webcontent, This is the code I use:
let logonPayload = {
  host: "https://sdtb-viya-emea.siemens-healtineers.com",
  authType: "server"
}

let store = restaf.initStore({casProxy: true});
let msg = await store.logon(logonPayload);
let {casManagement} = store.addServices('casManagement');

is your code  similar to this?

Dear Deva,
the code of the respective dashboards has two differences:

store.logon had no await but similar parameters
await store.addServices('identities') instead of await store.addServices('casManagement')

would one or both changes correct the behavior?

Michael:

store.logon is an async function since it might(in some circumstances) call other services. So an await is needed.
Since you are using cas, you need to change addServices as follows:
let r = await store.addServices('identities', 'casManagement'); Otherwise there is no links to cas services setup in the store. I am assuming you are calling identities to get the user name. It is ok to call addServices on the same service multiple times - restaf will reuse what is already there.

Data point:
Viya changed the default settings for CORS. This has caused issues for me. Still working with developers to understand why the new settings cause issues with access from user apps. So I set the defaults to the old default. But you should talk to your Viya admin about it. Below is my CORS setting.

Additional comments - using Firefox:
Firefox has additional security defaults that prevents writing cookies. So here is some info on how to deal with it:
Click the shield icon to the left of the address bar.
Select “Turn off Enhanced Tracking Protection” for that site.

Dear Deva,
I think there is a misunderstanding: In the case that I'm not working with the 'Authorize Access' setting, i.e., not working with elevated permissions, the code runs fine.
But in the case, elevated access is chosen, this JSON does not conform with the expectation of restaf. That's why I asked you here in this issue for a solution.
actually, the problem starts with a call to
let services = await store.addServices('casManagement', 'reports', 'reportTransforms');

Michael:
I was able to reproduce the issue with a newer version of Viya
This change to initStore helped my test app:
let store = restaf.initStore({casProxy: true});
let me know if it works.

Dear Deva,
our current code always uses with initStore variant. But we've always got this problem.

Here is a test app that you can deploy the same way you are deploying the failing app. See what happens.

change the extension to html
Edit file and change 'MICHAEL_SERVER" to your viya url.
deploy it to the same location as your failing app.
add the url of this app to the webcontent and try it.
This works for me, whether i logon as admin or not, but that is a just data [point.]

let me know what happens
micburger.txt
Just covering bases:
Not sure of all your settings, but one new wrinkle in Viya is that the sas.commons.web.security's content security policy must look something like this:
default-src 'self'; style-src 'self'; font-src 'self' data:; frame-ancestors 'self'; form-action 'self' your-cors-allowed-origins;
The your-cors-allowed origins but without the commas replaced by blank. My setting looks like this:
default-src 'self'; style-src 'self'; font-src 'self' data:; frame-ancestors 'self'; form-action 'self' https://localhost:8080 https://someweb.core.windows.net;

Dear Deva,
yes, that is working without a problem. The callback issue just happens when I actually load CAS data towards the frontend.

Oh, after replacing MICHAEL_SERVER with the complete protocol prefix, I get
ready
redirs:
{
"msg": "redirects completed"
}
file service:
{}
compute service:
{
"status": 400,
"statusText": "Request failed with status code 400",
"detail": "{"version":2,"httpStatusCode":400,"errorCode":5854,"message":"The attempt to run a Compute server as the user \"z0046trh\" failed because a service account credential could not be found for that user.","details":["path: /compute/contexts/ad76848d-01a3-418f-a8ab-b6b84342e82a/sessions","correlator: b7083128-1309-4453-ae23-406f2642e222"]}",
"error": true
}
(an issue with the context)
cas echo:
{
"metrics": {
"cpuUserTime": 0,
"memory": 233760,
"ioReadBlocks": 0,
"systemNodes": 1,
"cpuSystemTime": 0.000521,
"osMemory": 16674816,
"systemCores": 64,
"ioPageFaults": 0,
"elapsedTime": 0.000556,
"ioReadFaults": 0,
"ioReadBytes": 0,
"systemMemory": 0,
"voluntaryContextSwitches": 0,
"dataMovementBytes": 0,
"ioWriteBytes": 0,
"involuntaryContextSwitches": 0,
"systemTotalMemory":<PHONE_NUMBER>04,
"memoryQuota": 16674816,
"ioReadCalls": 0,
"ioWriteCalls": 0,
"ioPageReclaims": 0,
"ioWriteBytesCancelled": 0
},
"log": "NOTE: builtin.echo called with 1 parameters.\nNOTE:    parameter 1: code = {x = 1}\n",
"tables": {},
"tablesByName": {},
"logEntries": [
{
"level": "info",
"message": "NOTE: builtin.echo called with 1 parameters."
},
{
"level": "info",
"message": "NOTE:    parameter 1: code = {x = 1}"
}
],
"changedResources": [
"caslibs",
"tables",
"actionsets",
"datasources",
"caslibPermissions",
"actionPermissions",
"administrators",
"BWList"
],
"status": 0,
"results": {
"code": {
"x": 1
}
},
"disposition": {
"debugInfo": null,
"formattedStatus": null,
"reason": "OK",
"severity": "Normal",
"statusCode": 0
}
}
rest call:
{
"message": "Network Error",
"name": "AxiosError",
"stack": "AxiosError: Network Error\n    at f.onerror (https://unpkg.com/@sassoftware/restaf@5.2.4:7:56878)",
"config": {
"transitional": {
"silentJSONParsing": true,
"forcedJSONParsing": true,
"clarifyTimeoutError": false
},
"adapter": [
"xhr",
"http"
],
"transformRequest": [
null
],
"transformResponse": [
null
],
"timeout": 0,
"xsrfCookieName": "XSRF-TOKEN",
"xsrfHeaderName": "X-XSRF-TOKEN",
"maxContentLength": -1,
"maxBodyLength": -1,
"env": {},
"headers": {
"Accept": "application/json, text/plain, /"
},
"method": "get",
"url": "http://localhost:3000/api/test",
"withCredentials": true
},
"code": "ERR_NETWORK",
"status": null
}

Michael:

cas seems to be working - which was the original problem - so not sure why your app is failing.

A note on compute: Sounds like there are other restrictions on using the compute service - not really sure what Viya is saying. You should talk to some compute service expert and/or your Viya admin.

The other options are failing/working as intended in this version of the test app.

So we are still left with the mystery as to why your app is failing...
Deva

Dear Deva,the app is not failing for non-admins.CAS data loading is failing for admins only. Please read again.Regards Michael Burger
-------- Ursprüngliche Nachricht --------Von: devakumaraswamy @.> Datum: 31.10.24  18:22  (GMT+01:00) An: sassoftware/restaf @.> Cc: Michael Burger @.>, Mention @.> Betreff: Re: [sassoftware/restaf] Administrator login, CAS access callback (Issue #119)
Michael:
cas seems to be working - which was the original problem - so not sure why your app is failing.
A note on compute: Sounds like there are other restrictions on using the compute service - not really sure what Viya is saying. You should talk to some compute service expert and/or your Viya admin.
The other options are failing/working as intended in this version of the test app.
So we are still left with the mystery as to why your app is failing...
Deva
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Michael:
I have apps that read and update cas tables when logged on with or without admin rights.
As I recall you could not get past addServices('casManagement') - so unclear how you are saying it is the access to cas tables.
can you explain how you are reading the cas tables.
can you share a snippet of the code that is accessing data?
cheers...
Deva

Replace the runCas in the test app to this.. it does a simple read.
async function runCas(store) {
let { casManagement } = await store.addServices("casManagement");
let servers = await store.apiCall(casManagement.links("servers"));
let serverName = servers.itemsList(0);
let session = await store.apiCall(
servers.itemsCmd(serverName, "createSession")
);
let payload = {
action: "builtins.echo",
data: { code: { x: 1 } },
};
console.log(JSON.stringify(session.links("execute"), null, 4));
let r = await store.runAction(session, payload);
console.log("echo completed");
debugger;
payload = {
from: 1,
count: 20,
format: true,
table: { caslib: "Samples", name: "COSTCHANGE" },
};
let actionPayload = {
action: "table.fetch",
data: { table: { caslib: "Samples", name: "COSTCHANGE" } },
};
debugger;
let actionResult = await store.runAction(session, actionPayload);
console.log("------------------ results from fetch");
    console.log(JSON.stringify(actionResult.items("tables"), null, 4));
    console.log(JSON.stringify(actionResult.items("tableNames"), null, 4));
    await store.apiCall(session.links("delete"));
    return actionResult.items("tables");
  }

Michael:
Want to reiterate:
restaf itself has no visibility into the authorization rules for assets/apis. So if the call fails for an admin user only, then I would look for any authorization rules that are in play.
Deva

Dear Deva,
not really sure why: The issue is gone now. It might be connected with adding 'casManagement' more frequently or with some other sort of CAS crash we had in parallel.

@michburger
Glad to hear the issue is gone but wish we knew why it failed before.
I will close this ticket.
Thanks for being a user of restaf.
Cheers...
Deva