NullableToStringCall should not trigger on platform types (ie. String!)

I just ran the rule on our main and largest project. The rule triggered on many cases but only a few were real bugs. Most were harmless platform typed strings. Thinking forward a bit then the only way to resolve this is to type the platform types away. (ie. val foo: String = platformFoo). Being forced to do that is something I feel really is an orthogonal concern. ie.: "Disallow any interaction with platform types other than assignment to a kotlin type."
Expected Behavior of the rule
One of the cases that failed but really shouldn't.
val path = URLEncoder().encode("urlPath")
"https://www.google.com/$path"

Context
As I said above failing on this is a bit extreme. A separate rule regarding stricter usage of platform types seems like the way to handle that case. I am very new to Detekt so I apologize if this is consistent with the rest of the rules.

We do have another rule that is preventing Platform types but only on public APIs:
https://github.com/detekt/detekt/blob/master/detekt-rules-errorprone/src/main/kotlin/io/gitlab/arturbosch/detekt/rules/bugs/HasPlatformType.kt
I see your point, but the rule is just checking if you're calling toString() on a nullable type (and on platform types as well).
Therefore, this is a valid case:
val path = URLEncoder().encode("urlPath")
"https://www.google.com/$path"

If you specify the type explicitly, Detekt won't raise an issue anymore but your code will fail if the platform call returns null so the code smell still stays.
I think you should adapt your code to encapsulate platform calls so that you return either a String or a String?.

I get why you might want the strictness of this rule. What I experience is just that it is not very practical and it forces me to alter perfectly fine code to satisfy the rule. In my example path will never be null and there are many other methods in the JDK where the same is true.
What I am trying to say is that it is not really in the Kotlin spirit to treat platform types as nullable. The Kotlin way is to assume not nullable for external types. The Kotlin designers recognized in 2014 when they introduced platform types.

I must say that I do prefer this code:
val path = URLEncoder().encode("urlPath")!! // or val path: String = URLEncoder().encode("urlPath")
"https://www.google.com/$path"

If you know that it can't be null the usage of !! is safe. And, if something happends, you get the error where expected.
Right know intellij has some warnings pointing out that you should not use platform types and that you should decide if you want to treat it as nullable or no nullable.

What I am trying to say is that it is not really in the Kotlin spirit to treat platform types as nullable.

I see your point. Though we use the compiler type resolution, and a platform type is marked as a nullable type. So in this case, treating platform type would mean to add an exception that goes against the compiler semantic.
@BraisGabin snippet is great for your use case.
Plus as I mentioned before, I would encapsulate those APIs into a Kotlin-friendly API. You have to handle platform types only in one place and you don't pollute your codebase with @Suppress annotations.

I dont think I have any further arguments that might persuade you to do otherwise. It seems clear we diverge on what to expect from the rules but to sum up for any latecomers:
I would prefer if the rule was relaxed as described provided that a new rule would be created for being strict about platform types in the general case. The benefits of this is:

More in the spirit of Kotlin
Much more practical for introducing Detekt in an existing codebase
Existing behavior can still be achieved by using the new rule. A general strict rule about platform types also seem more in line with your arguments (though I guess this could be quite expensive to check).

Thanks for taking the time to discuss this 👍

Existing behavior can still be achieved by using the new rule. A general strict rule about platform types also seem more in line with your arguments (though I guess this could be quite expensive to check).

That's a really good point! You persuade me. We need a rule that ensure that you don't use platform types. And, if we have that rule, this rule should not check that, otherwise we could be raising two issues for the same problem.

This change is already implemented in 1.19.0-RC1 so we can close this.


can't selectStory in IE.

<EMAIL_ADDRESS>https://github.com/wKich/creevey/blob/master/src/server/selenium/browser.ts#L306
This line is not transpiled.
IE doesn't support object spread syntax, so it doesn't work.

Hi. Nice catch  👍. Thank you for reporting. I'll fix it today.

@kps-s-wada, I've released 0.7.27 with IE fix. Please give it to try.

Closed because of inactivity


Added release workflow

Implemented a basic create-release workflow that creates a new project release every time the user pushes a commit that contains a version number (ex: v1.0, v10.12.10).
Currently, the workflow creates a release with a version number that corresponds to the run number. A new tag is also created that corresponds to the version number.
This automation could be expanded by using the version number provided by the commit (rather than the run number) for the release version. Automated release notes and package building would also be nice features to add.

I'll check it tonight

hey was wondering if this could be checked again! I made a new push, thanks!

can you send me the workflow link where you tested this?

stash your changes and open the pull request once again


drag and drop column names into sql editor - unmarked text

I suggest that the 'column name' text won't be marked after the drag and drop into the sql editor.
It doesn't have much, if any, added value and just requires to press the arrow keys/mouse button to keep typing without deleting the copied column name.

This is controversial.  Most of text editors select dropped text (firstly to see what exactly was dropped, secondly to be able to delete it with one key). Perhaps we can make this configurable..

Actually you are right, probably it should stay like that. But perhaps the "copy column name(s)" option should be improved then, in 5.2.4 there is some sort of weird behavior of this function on mac - after clicking on "copy column name(s)" there is always a menu with "Maximize Result Panel" and "Set tab title" coming up.

There is no update almost a year.
Ticket is closed.
If issue is still actual for you feel free to create new ticket.


Create CDN routes

PUT /v1/cdn/upload > Upload a file to S3
DELETE /v1/cdn/:id > Delete a file from S3
GET /v1/cdn/:id > Get a access link from S3 and redirect


Release 0.21.0

What's Changed

Document release process by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/309
Remove log4j from project by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/306
Cleanup deprecation warnings in tests by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/305
Exception while the cursor is being committed by @a-liut in https://github.com/zalando-nakadi/fahrschein/pull/251
Fixes CursorManager README example misleading by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/312
JavaNet RequestFactory implementation by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/304
Dependency cleanup by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/321
Remove test code duplication by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/319
Adds ZStandard compression support by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/320
JDK11 client: Avoid copying of headers by @otrosien in https://github.com/zalando-nakadi/fahrschein/pull/322
Add documentation by @MALPI in https://github.com/zalando-nakadi/fahrschein/pull/315

Full Changelog: https://github.com/zalando-nakadi/fahrschein/compare/0.20.0...0.21.0

👍

👍


Introduce MBEDTLS_PSA_CRYPTO_CONFIG and use it for ECDSA

Description
These changes are the initial work to enable the conditional selection of PSA cryptographic features. This commit specifically sets up the initial infrastructure as well as changes to support conditional inclusion of the ECDSA algorithm. This new setup should allow for the existing code project to build and function by default, but also when MBEDTLS_PSA_CRYPTO_CONFIG is defined, allow for inclusion of the ECDSA algorithm by setting or not setting the PSA_WANT_ALG_ECDSA definition.
Fix https://github.com/ARMmbed/mbedtls/issues/3670
Status
READY
Requires Backporting
NO

Many configurations have failing unit tests. Probably a few more dependencies need to be modified but I haven't checked. The failing components in all.sh are:
test_no_hmac_drbg
test_everest_curve25519_only
test_depends_curves
test_depends_curves_psa
test_depends_pkalgs
test_depends_pkalgs_psa
test_psa_crypto_config_basic
test_psa_crypto_config_want_ecdsa

The test failures seem to be centered around changing the MBEDTLS_ECDSA_C to PSA_WANT_ALG_ECDSA in psa_crypto.c as described in the original ticket. I mentioned this in the ticket before, do we want to define PSA_WANT_ALG_ECDSA in config_psa.h when CONFIG_CRYPTO is not defined, or do we want to change psa_crypto.c to use PSA_WANT_ALG_ECDSA OR MBEDTLS_ECDSA_C for the guards. That way it will be backwards compatible.

do we want to define PSA_WANT_ALG_ECDSA in config_psa.h when CONFIG_CRYPTO is not defined

Yes, this way #if PSA_WANT_ALG_ECDSA is the way to test if psa_asymmetric_{sign,verify}(PSA_ALG_ECDSA) is supported, regardless of the configuration mode.

use PSA_WANT_ALG_ECDSA OR MBEDTLS_ECDSA_C for the guards

Then we'd have to change the guards everywhere. The test framework only supports #ifdef and #ifndef guards, not arbitrary preprocessor expressions, so we'd need to condense the test to a single symbol for the test suites anyway.

backwards compatible

It's backward compatible for what matters: if you have an existing configuration (without MBEDTLS_PSA_CRYPTO_CONFIG, since this didn't exist before) and relied on ECDSA being supported when MBEDTLS_ECDSA_C is defined, this will still be true.

Ok, there is a little more to the issue with some of the tests. Currently when executing ./scripts/config.py full it will automatically enable MBEDTLS_PSA_CRYPTO_CONFIG to ensure use of the new PSA_WANT_* flags. But for some tests it will then also unset flags like MBEDTLS_ECDSA_DETERMINISTIC assuming that feature will now be removed. But since the new crypto_config.h is included the PSA_WANT_ALG_ECDSA_DETERMINISTIC will be enabled. I could put a place holder in the crypto_config.h to place guards around the PSA_WANT for now until we can determine the best method for fixing up all the tests or fixing the full option in config.py to not set the MBEDTLS_PSA_CRYPTO_CONFIG for full builds.
For the new test_psa_crypto_* tests that turned out to be a new error in executing those tests not really related to the ECDSA or CRYPTO_CONFIG settings. When the test_suite_psa_crypto_se_driver_hal test executes it ends up calling the psa_driver_rappercipher_encrypt_setup() call and the location derived from lifetime is a value of 1, which forces the function to hit the default case and return PSA_ERROR_BAD_STATE. The test is checking for other errors that are ok in the is_status_smoke_free() call. I'm not sure if the is_status_smoke_free should be updated to also include the PSA_ERROR_BAD_STATE, or if the default error value returned should be something different. Is there are preference?

The philosophy of config.py full is that it enables every feature, i.e. everything that can be included or excluded is included, but it doesn't enable options that are switches between including X and including Y. (There are a few other limitations to full that aren't relevant here.)
MBEDTLS_PSA_CRYPTO_CONFIG switches between the old-style configuration mechanism and the new-style configuration mechanism, so it shouldn't be in the full config.
psa_driver_wrapper_cipher_{en,de}crypt_setup returning BAD_STATE for an unsupported location is a bug. The functions that continue a multipart operation should return BAD_STATE on an unsupported location because the operation shouldn't have been started if the location isn't supported. But setup() starts a multipart operation, so it should return NOT_SUPPORTED if there's no driver for the location.
I don't understand the problem with deterministic ECDSA, could you clarify? Which configuration is problematic, and what is the symptom?

Thanks for the clarification on those items. I will make sure that the MBEDTLS_PSA_CRYPTO_CONFIG does not get set when the config.py full is called. The issue I was seeing with deterministic ECDSA was with the test_no_hmac_drbg test. That test was setting up with config.py full, but then disabling MBEDTLS_ECDSA_DETERMINISTIC. But since MBEDTLS_PSA_CRYPTO_CONFIG was defined, it was also setting PSA_WANT_ALG_DETERMINISTIC and then the MBEDTLS_ECDSA_DETERMINISTIC was disabled. If I correct the issue with config.py I think it will fix that issue just fine.
I will also fix the BAD_STATE issue in the driver wrapper to return the correct error code for the setup function.

As of 76228ac, test_suite_psa_crypto_se_driver_hal is still failing when MBEDTLS_PSA_CRYPTO_CONFIG is enabled.

I'll double check that and push a fix shortly.

@gilles-peskine-arm Thanks so much for the helpful review comments. I appreciate the detailed comments.

@gilles-peskine-arm Looks like the change to remove the commented out MBEDTLS_PSA_ACCEL_ALG_* in psa/crypto_config.h now makes the CI builds fail for check-names for those defines being used in config_psa.h. Where should I add those definitions to since they do not belong in the crypto_config.h file?

tests/scripts/list-macros.sh looks for #define lines. That's what check-names.sh uses to enforce that any MBEDTLS_xxx macro used in the library must have a corresponding #define.
Since the potential MBEDTLS_PSA_ACCEL_xxx all correspond to a MBEDTLS_PSA_BUILTIN_xxx, I think adding this line to list-macros should do the trick to declare the ACCEL macros (untested):
sed -ne 's/^MBEDTLS_PSA_BUILTIN_/MBEDTLS_PSA_ACCEL_/p' <macros >>macros

The build failure on Windows is unrelated to this PR.
       "C:\builds\workspace\pr-multibranch_PR-3712-head-W6HWMYYVLHZ6EECF4FEU5NJXNGV4S3YH7ZGYXPIEBVO2FWQJJ74Q\worktrees\tmpbcqmg4aq\cmake_solution\mbed TLS.sln" (Rebuild target) (1) ->
       "C:\builds\workspace\pr-multibranch_PR-3712-head-W6HWMYYVLHZ6EECF4FEU5NJXNGV4S3YH7ZGYXPIEBVO2FWQJJ74Q\worktrees\tmpbcqmg4aq\cmake_solution\ALL_BUILD.vcxproj.metaproj" (Rebuild target) (2) ->
       "C:\builds\workspace\pr-multibranch_PR-3712-head-W6HWMYYVLHZ6EECF4FEU5NJXNGV4S3YH7ZGYXPIEBVO2FWQJJ74Q\worktrees\tmpbcqmg4aq\cmake_solution\tests\test_suite_psa_crypto_slot_management.vcxproj.metaproj" (Rebuild target) (138) ->
       "C:\builds\workspace\pr-multibranch_PR-3712-head-W6HWMYYVLHZ6EECF4FEU5NJXNGV4S3YH7ZGYXPIEBVO2FWQJJ74Q\worktrees\tmpbcqmg4aq\cmake_solution\tests\test_suite_psa_crypto_slot_management.vcxproj" (Rebuild target) (198) ->
         C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppBuild.targets(308,5): error MSB3491: Could not write lines to file "test_suite_psa_crypto_slot_management.dir\Debug\test_sui.FAEEC7BC.tlog\test_suite_psa_crypto_slot_management.lastbuildstate". The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. [C:\builds\workspace\pr-multibranch_PR-3712-head-W6HWMYYVLHZ6EECF4FEU5NJXNGV4S3YH7ZGYXPIEBVO2FWQJJ74Q\worktrees\tmpbcqmg4aq\cmake_solution\tests\test_suite_psa_crypto_slot_management.vcxproj]

Ugh. Sounds fun (not).

@gilles-peskine-arm Thanks for the review comments. I fixed the last two commits per the review comments.

As of a8b01e19e71d105ff1e77a39059a787b7238db06 the following all.sh components are failing: test_everest_curve25519_only test_depends_curves test_depends_curves_psa test_depends_pkalgs test_depends_pkalgs_psa. All the failures seem to be when ECDSA is disabled, with some code in psa_crypto.c trying to call ECDSA functions nonetheless.

As of ac692e8 CI is still not happy. One error:

Testing with only curve: MBEDTLS_ECP_DP_CURVE25519_ENABLED

CC    aes.c
CC    aesni.c
CC    arc4.c
CC    aria.c
CC    asn1parse.c
CC    asn1write.c
CC    base64.c
CC    bignum.c
CC    src/helpers.c
CC    blowfish.c
CC    pkwrite.c
CC    platform.c
CC    src/random.c
CC    pk.c
CC    ccm.c
CC    chacha20.c
CC    chachapoly.c
CC    cipher.c
CC    cipher_wrap.c
CC    pk_wrap.c
CC    cmac.c
CC    pkcs12.c
CC    ctr_drbg.c
CC    padlock.c
CC    src/drivers/signature.c
CC    src/drivers/cipher.c
CC    camellia.c
CC    pem.c
CC    pkcs5.c
CC    pkparse.c
CC    sha512.c
CC    des.c
CC    rsa.c
CC    dhm.c
CC    sha1.c
CC    sha256.c
CC    rsa_internal.c
CC    platform_util.c
CC    timing.c
CC    psa_crypto_driver_wrappers.c
CC    poly1305.c
CC    psa_crypto.c
CC    threading.c
CC    ecdh.c
CC    psa_crypto_se.c
CC    xtea.c
CC    psa_crypto_slot_management.c
CC    version_features.c
CC    ../3rdparty/everest/library/everest.c
CC    ../3rdparty/everest/library/x25519.c
CC    psa_crypto_storage.c
CC    psa_its_file.c
CC    ecdsa.c
CC    src/drivers/keygen.c
CC    ecjpake.c
CC    ../3rdparty/everest/library/Hacl_Curve25519_joined.c
CC    ecp.c
CC    x509.c
CC    x509write_crt.c
CC    x509_crl.c
CC    pkcs11.c
CC    x509_create.c
CC    memory_buffer_alloc.c
CC    md.c
CC    version.c
CC    x509_csr.c
CC    certs.c
CC    x509_crt.c
CC    hkdf.c
CC    error.c
CC    md5.c
CC    ecp_curves.c
CC    md4.c
CC    entropy.c
CC    havege.c
CC    hmac_drbg.c
CC    gcm.c
CC    oid.c
CC    md2.c
CC    entropy_poll.c
CC    nist_kw.c
CC    ripemd160.c
CC    x509write_csr.c
CC    debug.c
CC    ssl_msg.c
CC    ssl_cookie.c
CC    ssl_ciphersuites.c
CC    net_sockets.c
CC    ssl_srv.c
CC    ssl_cache.c
CC    ssl_cli.c
CC    ssl_ticket.c
CC    ssl_tls.c
CC    ssl_tls13_keys.c
In file included from ../include/mbedtls/ecp.h:43:0,
from ../include/psa/crypto_extra.h:564,
from ../include/psa/crypto.h:3780,
from psa_crypto.c:26:
psa_crypto.c: In function 'psa_ecdsa_sign':
psa_crypto.c:3563:26: error: implicit declaration of function 'mbedtls_ecdsa_sign_det_ext' [-Werror=implicit-function-declaration]
MBEDTLS_MPI_CHK( mbedtls_ecdsa_sign_det_ext( &ecp->grp, &r, &s,
^
../include/mbedtls/bignum.h:50:22: note: in definition of macro 'MBEDTLS_MPI_CHK'
if( ( ret = (f) ) != 0 )
^
psa_crypto.c:3573:26: error: implicit declaration of function 'mbedtls_ecdsa_sign' [-Werror=implicit-function-declaration]
MBEDTLS_MPI_CHK( mbedtls_ecdsa_sign( &ecp->grp, &r, &s, &ecp->d,
^
../include/mbedtls/bignum.h:50:22: note: in definition of macro 'MBEDTLS_MPI_CHK'
if( ( ret = (f) ) != 0 )
^
psa_crypto.c: In function 'psa_ecdsa_verify':
psa_crypto.c:3624:11: error: implicit declaration of function 'mbedtls_ecdsa_verify' [-Werror=implicit-function-declaration]
ret = mbedtls_ecdsa_verify( &ecp->grp, hash, hash_length,
^
AR    libmbedx509.a
AR    libmbedtls.a
cc1: all warnings being treated as errors
Makefile:265: recipe for target 'psa_crypto.o' failed
Makefile:17: recipe for target 'lib' failed
make[1]: *** [psa_crypto.o] Error 1
make: *** [lib] Error 2
Failed to build: only MBEDTLS_ECP_DP_CURVE25519_ENABLED
^^^^test_depends_curves: test/build: curves.pl (gcc): tests/scripts/curves.pl -> 1^^^^

Done, cleaning up
Thu Oct 15 02:37:51 UTC 2020

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
FAILED: 1
test_depends_curves: test/build: curves.pl (gcc): tests/scripts/curves.pl -> 1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

@ronald-cron-arm Can you look at the recent comments and let me know how to proceed? Hoping we can get this finalized and merged soon so I can start new PRs for the follow on tasks.

@ronald-cron-arm I made fixes to all.sh script based on the review comments. Were there any other outstanding issues to correct?

I seems that the following comments are not completely addressed:
https://github.com/ARMmbed/mbedtls/pull/3712/files#r508239875
https://github.com/ARMmbed/mbedtls/pull/3712/files#r510685478
https://github.com/ARMmbed/mbedtls/pull/3712/files#r503520451

@ronald-cron-arm Thanks for the prompt feedback. I made additional corrections that should address the remaining comments.

@gilles-peskine-arm Looks like there are some build failures, but I can't see the details. Can you let me know what I should address? Thanks.

There was a failure in the -head job, but it was due to a network glitch. I've restarted the job just to be sure, but since the -merge job succeeded, there shouldn't be any problem.

@gilles-peskine-arm Thanks for helping with all the review. There seems to be some pending requested changes from @ronald-cron-arm . I think those items were addressed already so hopefully those can be closed.

@yanesca This is only a partial implementation of the new feature: it only works for a single library module. It isn't really practically usable yet. So I think it's too early for a changelog entry.


Add flow type definitions

Closing -- as @mourner points out, this will be brittle unless we're using Flow more comprehensively in the repo.


[FEATURE] Using Cookies - Club Login 🚀

Description
Cookies 🍪
Currently we are using sessionStorage.setItem("token", response.data.token);  - Session Storage in our Club Login which is not much safe, so we would like to use Cookies which appears to be much safer !
ONLY , make this changes in Clubs login.
Screenshots
Code

Site

Additional information
File name :
Milan\src\pages\clubs\ClubsLogin.jsx - For Clubs Login page
Milan\server\routes\Clubs.js - For Clubs Login backend.

I will do it tomorrow :)


can't initialize on Android and I'm stuck buffering.

What is the need and use case of this feature?
It sets up normally in ios, but not in android. It stays buffering. Why is that?
ios log

android log

SetupService.ts

App.ts

usecase.ts

try snipping the media src network request first with eg HTTPToolkit

I am facing the same issue (using react-native: 0.72.15). Downgrading to 4.0.0-rc04 fixes the issue for me which shows it's not a network issue...

I have the same problem, does the current version work on Android for anyone?

We are having the same problem with RN 0.72.15. 😬 Any updates on this issue?

@Brightbong92 did you find any solution to this?

@c-goettert
I am sharing the method that I have solved.
// useSetupPalyer.ts
import { useEffect, useState } from 'react';

import TrackPlayer from 'react-native-track-player';

import { SetupService } from '@/utils/track-player';

export interface UseSetupPlayerProps {
  cb?: () => Promise<void>;
}

export function useSetupPlayer({ cb }: UseSetupPlayerProps) {
  const [isPlayerReady, setIsPlayerReady] = useState<boolean>(false);

  useEffect(() => {
    let unmounted = false;
    (async () => {
      await SetupService();
      if (unmounted) return;
      setIsPlayerReady(true);
      const queue = await TrackPlayer.getQueue();
      if (unmounted) return;
      if (queue.length <= 0) {
        cb && cb();
      }
    })();
    return () => {
      unmounted = true;
    };
  }, []);

  return isPlayerReady;
}

// useHooks.ts
const track1 = {
  url, // Load media from the network
  title: 'Avaritia',
  artist: 'deadmau5',
  album: 'while(1<2)',
  genre: 'Progressive House, Electro House',
  date: '2014-05-20T07:00:00+00:00', // RFC 3339
  artwork: 'https://example.com', // Load artwork from the network
  duration: 0, // Duration in seconds
};
...
  const addPlayer = useCallback(async () => {
    await TrackPlayer.add([track1]);
  }, []);

const isPlayerReady = useSetupPlayer({ cb: addPlayer });
...
return {
   ...
   isReady: isPlayerReady
   ...
};

// view.tsx
...
const {isReady} = useHooks();
...
return (
  {
    isReady ? <Text>show</Text> : <Text>loading...</Text>
  }
)

Thanks for posting you solution @Brightbong92 . Indeed I found out that for me it was something else that has caused the bug: I was calling TrackPlayer.reset() immediately before starting the Player without waiting for it. Something like:
...
await TrackPlayer.setupPlayer()
...
TrackPlayer.reset()
...
await TrackPlayer.add([track])
TrackPlayer.play()

As the reset call is asynchronous it also removed the track I added to the queue immediately after the call. I could fix it by adding an await to the reset function (it returns a promise). This issue can be closed from my perspective.


Explore "sumo" module

BlazorSodium is using what I think is the "standard" version of libsodium.js.  Libsodium also has a "sumo" version which includes more functionality.  Explore the sumo version and ways to make the sumo APIs available to those who want it.

BlazorSodium 1.2.0 switched to the "sumo" version of libsodium.  This was necessary in order to continue supporting password hashing functionality.


Add an ellipse standard library function to KCL

We need the ability to define ellipses in KCL. Since ellipses are by definition closed profiles, I think it should not require a startProfileAt but should be a SketchProfile in its own right (when we support multiple profiles per sketch).
Proposed API
ellipse(majorAxisLength: number, minorAxisLength: number, profile: SketchGroup, tag?: Tag) -> SketchProfile

Other considerations

After implementation, the circle function could be made a thin wrapper on this function that just has majorAxisLength == minorAxisLength

Currently there's no way to implement elliptical curves in the engine.  There are straight lines, arcs, and cubic bezier curves, but none of these options could make a fully accurate ellipse.
Best way i can think of to currently implement this ellipse kcl stdlib function is using 4 cubic bezier curves, but this will deviate from the ellipse as eccentricity increases.  Does anyone have a better approach?  or perhaps a plan to implement some sketch primitive in the engine that could draw an ellipse more accurately?


[Android] Fix: regressions in AnchorScrollView.

Fix: blank screen is displayed just after render, little bit of scroll is required to get content displayed.
Fix: not scrolled to first unread messages in ~20% of time.

Cool!


Allow for Nans in input of Permutation Importance

https://github.com/TeamHG-Memex/eli5/pull/381/ by @Matgrb

Thanks @Matgrb

Thanks @Matgrb


Support more than 2 decimal places in decimal data types

In the SQL Server type mappings, "decimal" is mapped to "decimal(18,2)".
I have some decimal data with more than 2 decimal places, and this type mapping causes data loss when the data is accessed in a trigger.
The maximum precision of a Decimal in SQL Server is 38, so I'd suggest using this. The choice of scale is more subjective, but I'd suggest using 10 - this would still allow for 28 digits before the decimal place, a significant increase on the current value. Thus, I'd suggest using a type mapping to "decimal(28,10)".

Happy to close this, because I discovered that I could achieve what I needed by extending the SqlServerTypeMappings class


Saving only changed and valid fields

by @michaelsorich, at https://github.com/xpepermint/vue-contextable/issues/4
I will eventually have a rather large model and I intend to regularly autosave the model via a rest api. I intend to send only the fields and values that have changed since the last save which typically will only be a small fraction of the model (I could send a serialized version of the complete model and let the server sort it out, but I am hoping that I can do so on the client and only send the pertinent changes).
The presence of one or more fields that are currently invalid will not prevent saving. Currently I am intending that fields that are invalid will not be sent to the server for saving, but other valid changed fields will be sent (even though some fields are invalid).
Thus, “if (m.isChanged() && m.isValid())” isn’t quite what I wish as it will only be true if all fields are valid. As long as there is at least one field that is both changed and valid then the result should be true (i.e. there is data that can be sent to the server as a partial update/PATCH). I am happy to implement this as a new method on extended model and field classes so this is not too much of an issue if I can work out how to properly extend Model and Field.
In vue-contextable, the construction of the Model instance is not explicit. For example, I cannot see something like ‘let m = Model(…)’ - if so it would be trivial to substitute my extended version of the ReactiveModel.
Based on the example, my understanding of the standard setup is:

A contextable context object is made (const context = new Context())

Then a schema is passed in which appears to create a contextable.Model instance (e.g. context.defineModel('User', new Schema(…)) which is then stored in the context object. It would not seem easy to replace Model with an extended version at this stage without rewriting context.defineModel and createModel.

It is possible to access the Model from the context but not to set the model which seems to make it difficult to replace it with an extended version at this stage (e.g. class Modelv2 extends context[‘Lease’]{…}; context[‘Lease’] = Modelv2).

I presume that somewhere in the initialisation process (not sure where) the defineReactiveModel function from vue-contextable is called which retrieves the model from the context, extends it (to become a ReactiveModel), and then stores it in the vm variable. It is not clear to me how I would override the ReactiveModel definition (which is itself embedded in a defineReactiveModel function) in order to replace it with an extended version which would be called by the appropriate function in the course of initialization.

There is likely a much simpler way of extending the functionality of ReactiveModel and Field but I am not seeing it at the moment. Any hints would be appreciated.

I will eventually have a rather large model and I intend to regularly autosave the model via a rest api. I intend to send only the fields and values that have changed since the last save which typically will only be a small fraction of the model (I could send a serialized version of the complete model and let the server sort it out, but I am hoping that I can do so on the client and only send the pertinent changes).

That's something that contextable should include by default. It's a useful feature so let's add it. This is what I propose:
// model schema example
new Schema({
  instanceMethods: {
    async autoSave () {
      let data = this.toObject({
        onlyChanged: true,
        onlyValid: true
      });
      // post data to the server
    }
  }
})

In vue-contextable, the construction of the ReactiveModel instance is not explicit. For example, I cannot see something like ‘let m = ReactiveModel(…)’ - if so it would be trivial to substitute my extended version of the ReactiveModel ...

I agree and I'll see what I can do about that.

A quick follow up ... I started upgrading the underlying objectschema package. I hope I'll finish it by tomorrow. After this upgrade a new filter method will be available thus you will be able to extract an object with keys that pass the test:
model.serialize() // -> convert to Object
model.filter((field) => field.isChanged() && field.isValid()) // -> convert to Object with changed and valid keys

The filter method looks good. I would be interested in your thoughts about how best to link this to commit - basically the object with valid changes represents the changes that are valid since the last patch to the server database. Thus, simultaneously (or as close as possible) I would like the fields that are returned from filter (i.e. valid and changed) are also commited so that they are not returned by a repeat call to filter (unless there are subsequent changes). As the save may be taking place as a user is still modifying the form (i.e. the save would preferably not block user working on the form) it would be good for the commit and extraction of changed-valid fields to occur together.

This feature took a while because I had to rethink the whole concept. The main question was how to deal with nested fields. The latest package v3.0.0 is now easily extendable. It's also built on top of the latest ObjectSchema.js which provides new methods like flatten(), filter(), collect() and scroll().
Partial save/commit should now be easily achievable like this:
await model.validate({quiet: true});
...
let patch = model.filter(({path, field}) => {
  if (field.isChanged() && field.isValid()) { // if field has been changed and is valid
    field.commit(); // commit field value
    return true; // add it to the result object
  }
}); // -> serialized object with only valid fields

This is something you should pack into a class or instance method of a model.

I will eventually have a rather large model and I intend to regularly autosave the model via a rest api.

I would suggest that you execute the autosave feature on blur event or make a debounced POST action to the server.

I am happy to implement this as a new method on extended model and field classes so this is not too much of an issue if I can work out how to properly extend Model and Field.

Use Schema mixins to extend a model. Note also that a Model is actually a pure javascript class/function thus you can simply do Admin extends User {}.
Please reopen this issue if this doesn't fully work for you.


Broken link for the Interface endpoint properties and limitations

Updated with the proper link for the Interface endpoint properties and limitations
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you for flagging the incorrect links.


Traced law not well-typed?

specifically track s <<= track t x = track (s <> t) x.
I was trying to prove one of my own instances was law-abiding but ran into trouble here:
track s <<= track t x = extend (track s) (track t x), where extend :: (w a -> b) -> w a -> w b and yet the second argument to extend has type track t x :: b and not w b as expected.

I think it should be (track s =<= track t) x = track (s <> t) x

I believe it, since my instance obeys it. Thanks!


Pi Finder Can't Find My Pi

I have my Pi all set up and connected to ethernet but when I click the "Find My Pi" button it fails and gives the error: "Your Pi could not be found. Are you sure it is attached to the network?" I'm far from an expert at this so it's probably something I did wrong.
OSX
Raspberry Pi 4
Pi Finder 3.0.0

Same here ! Didn't tried with a rpi 3 to see if the issue is with new Pi.

I have the same issue with my Pi 4. I can ping and ssh into the pi just fine from command line, but pi finder doesn't find it.
Windows 10
Raspberry Pi 4 4GB
Pi Finder 3.0.0

Confirming this issue persists. Pi Finder can't find my Pi 4s. They're on the same wired ethernet as the Pi Finder machine, and reply to ping and ssh.
This looks like a great tool for the bootstrapping capability--here's hoping it isn't dead!

Confirming this issue persists. Pi Finder can't find my Pi 4s. They're on the same wired ethernet as the Pi Finder machine, and reply to ping and ssh.
This looks like a great tool for the bootstrapping capability--here's hoping it isn't dead!

hi this is not maintained. if someone wants to submit PRs to fix we'll take a look. ideally someone would take it over.

hi this is not maintained. if someone wants to submit PRs to fix we'll take a look. ideally someone would take it over.

Same issue for me, however could this because I have renamed the hostname to a custom one? Is the device hostname hardcoded into the source?


[Bug] BoxBilling seems to not acknowledge failures in server management functions

What happened?
I noticed this while working on on my CWP server manger, but it seems like BoxBilling treats a failure as a success.
Reproduction Steps

Enter wrong server API key
Order server management as a client
Account creation is rejected because of the incorrect API key
BoxBilling still marks the account as active even though it wasn't.

This happens no matter what I return back from the function. The only way to ensure BoxBilling will mark the account creation as failed is to kill the function without returning a result.
It looks like the code is using boolean logic, so I have trued returning both false and 0 on failures which should be equal the desired result, but to no luck.
Also, the server test connection will always say the test was successful.
BoxBilling Version
Current Master Branch
What version of PHP are you running?
7.4x
Additional Notes
N/A

I'm pretty sure this is the intended functionality


The full type name of parameter type Int32 is not correct

While running Update-MarkdownHelp with the parameter -UseFullTypeName, the  generated full type name of Int32 would be System.Nullable1[[System.Int32, mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089]]`.
Is the behavior a bug or something by design? The expected behavior should be System.Nullable`1[[System.Int32]].

cc @yishengjin1413

@vors Qinezh is a dev in my team. pls help on this question.

@yishengjin1413 implemented the full type name support.
I'd suggest to strip out the Nullable part even in the full type name case.
Technically the [System.Int32, mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089] is a valid dotnet type name, but definitely it's not the desired behavior.

@vors How about use ParameterType.ToString() to get the fulltype? I tried and it return System.Nullable`1[System.Int32], which is much better for us.

@yishengjin1413 sure, go ahead

@vors I created a PR here to fix this issue. Please have a check.

Fixed in #309


thumbnail in discord

Expected behavior
When promoting post in Discord, users want to see the thumbnail as it works for steemit
Actual behavior
Link shown, post preview shown, but no thumbnail
How to reproduce
Simply put a busy link to post in discord, you may choose to paste an image in your post OR link the image, same result

Browser: all
Operating system: all

This issue was resolved for a few days, now again there is no thumbnail.

It seems to be working now:

This bug keeps bugging people. Today jerrybanfield reported it. If this issue is closed, can it be reopened or I need to open another?


Link to an online Bible instead of an API

I don't understand why a link to the API is in the header. I think it would be better to either remove the link and just display the reference, or link to an online Bible.

Hi @BravishkaSkytano this could be changed in setting.

I saw that, my only problem with it is that it removes the reference (e.g. John 1:1).

But Link to an online Bible instead of API will be a good idea


remove extra spaces on attachment modal

Details
After final design agreement here, we need to apply conditional marginTop, marginBottom in modal per devices, along with paddings.

Platform
isSmallScreenWidth
margin:20
topSafeAreaMargin
bottomSafeAreaMargin
topSafeAreaPadding
bottomSafeAreaPadding

iPhone
Yes
❌
❌
❌
✅
❌

Android
Yes
❌
❌
❌
❌
❌

iPad
No
✅
✅
✅
❌
❌

Tablet
No
✅
❌
❌
❌
❌

Web/Desktop
No
✅
❌
❌
❌
❌

Fixed Issues
$ https://github.com/Expensify/App/issues/10352
PROPOSAL: https://github.com/Expensify/App/issues/10352#issuecomment-1274901151
Tests

Login with any account
Send or receive any attachment in any chat
View attachment detail
Verify that no extra space is added above and below attachment

[x] Verify that no errors appear in the JS console

QA Steps

Login with any account
Send or receive any attachment in any chat
View attachment detail
Verify that no extra space is added above and below attachment

[ ] Verify that no errors appear in the JS console

PR Review Checklist
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The reviewer will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots
Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@shawnborton Can you help here verify the screenshots and the table for the expected behavior (in the PR body)?

This looks good to me!
Minor thing - I noticed on mobile web Safari that the top area above the modal header isn't white... I don't think that's related to anything we're doing here but probably something we should fix at some point, if possible?

@aimane-chnaif the changes look fine, can you resolve the conflicts and update? So that I can start with the testing?
Also one more thing, it'll be great to add iPad screenshots for this one.

No. I mean iPad screenshot for attachment padding. If you've already uploaded then can you tag them accordingly?

Changes look fine and I was able to test different (small/high, wide/long images), etc. on different platforms.
🎀 👀 🎀
C+ reviewed

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

iPad

Android

@Gonals Quick bump on this one.

@aimane-chnaif, great job getting this Expensify/App pull request over the finish line! I just merged it.
I know there's a lot of information in our contributing guidelines, so some points to take note of:
Once your PR is merged, you can be hired for another issue. Once you've completed a few issues, we may start hiring you for more than one issue at a time.
Once your PR is deployed to our staging servers, it will undergo quality assurance (QA) testing. If we find that this doesn't work as expected or causes a regression, you'll be responsible for fixing it. Typically we would revert this PR and give you another chance to create a similar PR without causing a regression. (I don't imagine this will happen with this PR, but it's something to be aware of)
Once your PR is deployed to production, we start a 7-day timer. After it has been on production for 7 days without causing any regressions, then we pay out the Upwork job.
So it might take a while before you're paid for your work, but we typically post multiple new jobs every day, so there's plenty of opportunity. I hope you've had a positive experience contributing to this repo!

🚀 Deployed to staging by @Gonals in version: 1.2.25-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @yuwenmemon in version: 1.2.25-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Slack OAuth

This is the biggest feature request I can think of. Feel free to blow it off. The reason I raise it is that our newsroom, like many, uses a mix of Microsoft Active Directory and Slack for its authentication, but not Google. If you can get this app to interface with Slack for signins, I think you'd open it up to wider range of users. Though of course if you don't have time or the interest, that would be totally understandable.

Hey @palewire,
While we definitely want to consider additional sign-in method support, if you're able to invest some time you could create a custom userAuth.js to interface with the Slack passport strategy.  This would allow for your customized version of library to integrate with Slack using our current customization model.

I am considering taking a run at this feature, has anything significant changed with the project or technology since I filed the ticket you think I need to keep in mind?

Good news. I was able to make Slack auth work with this change to userAuth.js
https://github.com/datadesk/library/blob/master/server/userAuth.js
One trick, though. Placing that file in my customization repo didn't work as an override with my Heroku deploy. It would till try to auth with Google despite this file being there.
https://github.com/datadesk/library-customization/blob/master/userAuth.js
It's possible I didn't setup the override file right, but to make it work I had to fork your core repo, override the internal server/userAuth.json and deploy that instead.


Update readme in hmrc folder to include documenation for "Gov-Client-Local-IPs-Timestamp" header

https://github.com/intuit/user-data-for-fraud-prevention/tree/master/src/js/hmrc
Update readme to add details for a new header we added recently.
Gov-Client-Local-IPs-Timestamp - A timestamp to show when Gov-Client-Local-IPs header value is collected.

Hey, @skodamarthi Can I work on this?

@Swastyy Sure...This is open for anyone to contribute. Please submit a PR when you can and we are happy to help if you have any questions.

Hi
I presume this can be closed?


[WIP] Set up microservices CI/CD

What does this pull request aim to achieve? 💯
Setting up microservices CI/CD. Resolves #1478

[X] I have checked that no one else is working on similar changes.
[X] I have read the latest README and understand the development workflow.
[X] The name of this branch is: feature/<branch_name>, or hotfix/<branch_name> if this is a hotfix. The branch is created in a cloned version of this repo, not a forked repo.
[X] This branch is rebased/merged with the latest staging (or the latest production if it is a hotfix).
[X] There are no merge conflicts.
[X] There are no console warnings and errors.
[X] On the right hand side of this PR, I have linked the appropriate issue(s) under "Issues" and added a project progress under "Projects".

Still a WIP as I need to add the workflow files for staging and production, but I did test that the review workflow works and the Lambda is deployed successfully to the review environment. Please provide as much feedback as possible about possible improvements, etc. Thanks!

Hi @mannykary ,
If we have separate directory services with services inside it (notifications, messages, other functionalities) will it possible this way to deploy only for example notifications?
I would also like to add test folder to every microservice, but I guess we can add it later.

Hi @mannykary ,
If we have separate directory services with services inside it (notifications, messages, other functionalities) will it possible this way to deploy only for example notifications?
I would also like to add test folder to every microservice, but I guess we can add it later.

Yes, since we have a separate Github Actions file for each service, and we have added a path matcher to trigger the build only if there are changes in the notifications folder, it should be possible to deploy just one service; see https://github.com/FightPandemics/FightPandemics/blob/5b8e2b0d63ba457c3520c240325872c93a056f8e/.github/workflows/review-notification-service.yml#L9

@brufen I have added stub unit tests running in Mocha/Chai, and also added a job to the Github Actions workflow to run the unit tests prior to deploying. If the unit tests fail, then it will not deploy.

I think the review workflow works well now, so I went ahead and added workflow files for staging and production, and moved the PR out of Draft.


modifying collate behavior of Dataloader

Hello, I precomputed the indices of neighboring nodes of different degrees for each node and store them in the Data (i.e.,
Data(x=x, edge_index=edge_index, edge_attr = edge_attr, focal_nodes_deg1 = focal_nodes_deg1, neighbor_nodes_deg1 = neighbor_nodes_deg1, ...),
Here, focal_nodes_deg1 is the indices for all nodes of degree 1, neighbor_nodes_deg1 are all indices of neighboring nodes for those focal nodes. Since I'm dealing with molecules, there are limited number of degrees.)
When I try to batch the data, the above two indices need to be modified according to the batch. Otherwise, these indices refer to the wrong nodes in the giant batched graph. So I need to modify the collate function of DataLoader to take batch.batch into consideration. However, it seems collate_fn is disable in DataLoader as the source codes of it shows:
        if "collate_fn" in kwargs:             del kwargs["collate_fn"]
any ideas on how to solve this problem? calculating neighboring indices on the fly is very computationally expensive.
Btw, I read the advanced Mini-batch tutorial but that seems to only teaches me how to modify the edge_index and other attributes related to the whole graph

Rather than modifying collate_fn, you probably want to modify Data.__inc__ to ensure that indices in focal_nodes_degx are incremented correctly. This should be done by default if you simply rename your attributes to something like focal_node_index_deg1 (containing the word index).
If you want to modify collate_fn, you can directly make use of the torch.utils.data.DataLoader with customized collate_fn. The current PyG dataloader does the same (and therefore restricts modifying collate_fn).


remove useless row

no need to set key again

I think I understand the purpose of this line: when the content of the object is the same but the pointer is different, replace it with the current object


[BUG] Error loading Manga List

Describe the bug
After logging in as a guest, I get the error "Error loading Manga List".
To Reproduce

Open mangadesk
Log in as a guest

Expected behavior
Gives a list of various manga titles.
Screenshot

Environment

OS: Ubuntu
Version: 20.04
Mangadesk v0.6.2

Maybe the changed something in the API again.

yup API issue. will look into this when im free.
thanks for reporting!


Remove embedding from Document

This was a design decision way back taken from how langchain (python) was designed.  In practice, this doesn't seem useful.  It acts like a sort of cache, if you are writing the same document to the vector store multiple times, which doesn't seem realistic.   If you have a use case for keeping the embedding in the Document, please comment.

The SimpleVectorStore relies on the presence of the "embedding" field in Document.

The AzureVectorStore also relies on the presence of the "embedding" field in Document. The doAdd method has the following line of code in the 1.0.0-M4 version of Spring AI.
searchDocument.put(EMBEDDING_FIELD_NAME, document.getEmbedding());

The SimpleVectorStore relies on the presence of the "embedding" field in Document.
This PR https://github.com/spring-projects/spring-ai/pull/1822 addresses this.

We need to review all the vector store impls and make appropriate modifications.  I noticed the Neo4jVectorStore also uses the 'getEmbeddings' method as sort of simple data structure to pass things along while adding.  It can be refactored.

If possible, it would be great to get https://github.com/spring-projects/spring-ai/pull/1794 merged before start removing the "embedding" field, mostly to avoid many many merge conflicts since they touch the same code area 😅

We need to review all the vector store impls and make appropriate modifications. I noticed the Neo4jVectorStore also uses the 'getEmbeddings' method as sort of simple data structure to pass things along while adding. It can be refactored.

Created https://github.com/spring-projects/spring-ai/issues/1826 to track this.


Fix potential buffer overrun

This commit rearranges record size comparison and fread() to make sure
fread() only reads the data that can fit into the buffer.

Whoa, thanks!


chore(main): release 0.3.3

:robot: I have created a release beep boop
0.3.3 (2023-07-30)
What's Changed

fix(deps): update dependency com.materialkolor:material-kolor to v1.2.2 by @renovate in https://github.com/Mouwrice/proguard-core-visualizer/pull/75

Full Changelog: https://github.com/Mouwrice/proguard-core-visualizer/compare/v0.3.2...v0.3.3

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Mouwrice/proguard-core-visualizer/releases/tag/v0.3.3 :sunflower:


fix(replayer): replay corpus files in hidden dirs

The replayer would not execute hidden corpus files or files in hidden directories if they were in the bazel project root (#253).

The fix looks good to me. Hidden files can always be filtered out with a glob in Bazel, which is far more flexible.
Wouldn't hidden files in subdirectories also have been filtered out though? This doesn't look specific to the root (d_name should just contain the basename of an entry).
@stefanbucur Could you review this for approval?

Thanks for taking a look @fmeum!
I think hidden files in sub directories works for me since the replayer is started with a prepared corpus directory with file names based on the full path inside the bazel project. E.g. src/.hidden/foo end up in the corpus directory as src-.hidden-foo which was not filtered out (see https://github.com/bazelbuild/rules_fuzzing/blob/691c8938ff87681f7281cc4ba840e74e3b63c54b/fuzzing/tools/make_corpus_dir.py#L63).

@stefanbucur I added a second commit to update the upload-artifact action. This should get the OSS Fuzz github workflow going again. Could you take another look?


WinGet on Windows Server Core

I'd like WinGet to function correctly on Windows Server Core. The main gap identified by @jantari was related to the way WinGet determines the locale for package metadata.
Quote from the discussion below:
I looked into it and this API does appear to not be present in Server Core (meaning this error from our call to it is expected).  That of course depends on my ability to map from the internal identifier to the marketing name, which should not be considered infallible.
I think at this point we could confidently wrap the implementation of Locale::GetUserPreferredLanguages to prevent the error from escaping.  The default state would be that locale was not included in the installer selection if the call failed.
This is a good workaround in the interim.
Originally posted by @JohnMcPMS in https://github.com/microsoft/winget-cli/discussions/2361#discussioncomment-8559871

Some additional context and thoughts for this issue. I will refer to Windows Server's default install, without Desktop Experience, as "Windows Server Core" or "Server Core" for brevity, even though that term is no longer officially correct.

The goal is to get winget shipped in-box with Windows Server 2025 Core installations, and easier to get going on Windows Server 2022 Core installations. Currently the bootstrapping process is very involved and kind of hacky.
In my own VM-based testing with Server 2022 Core, this one API call: https://github.com/microsoft/winget-cli/blob/180a8d7d5ad3fe90c3a038f9e5ffda5ae77c289a/src/AppInstallerCLICore/Workflows/ManifestComparator.cpp#L629-L633 failing is the last blocker before the all-important winget install command can run successfully. No further workarounds, shims or shenanigans needed. This means we're already "close to the finish line" on Server Core compatibility.
The above API call does succeed on Windows Server Core 2022 with the AppCompatibility FoD installed
There seem to be more errors/blockers for getting winget to run on Server 2019 Core. I wasn't able to investigate and solve these, but I'd be totally happy if it worked on 2022 and 2025 Core first. 2019 Core would be nice to have later.
Winget has already been announced to ship as part of the default Windows Server 2025 with Desktop Experience install. This is great, but the Desktop Experience install is a huge compatibility bandaid you'd only use when absolutely necessary, and many environments therefore mix both Core and Desktop-Experience deployments. The inability to use winget across them all is a blocker to its adoption even if it were partially available OOTB.
Some ideas for addressing the failing Locale::GetUserPreferredLanguages API call:

Find and use an alternative API that works on Server Core, or be naughty and get the locale from the registry somewhere as a fallback
Catch the error and just default to a packages' DefaultLocale when the user's preferred locale cannot be determined (I believe this is what  @JohnMcPMS suggested in their own words)
You said a locale is required to use the "msstore" source so just block/refuse installs from the "msstore" source when the user's preferred locale cannot be determined - just like when the source agreements weren't accepted. I personally, and I imagine many business customers, will exclusively use private package repositories for software deployments to Servers anyway and never the community repo or msstore.

In addition to the Locale-API blocker discussed above, you also brought up that we also don't have a good way to determine which packages are suitable for an environment with no desktop experience. I firmly believe this is not on winget to solve and doesn't have to be addressed together with the Locale API issue or to ship winget inbox with Windows Server Core. Still, some additional thoughts for when there is time to address this:

Package compatibility with Windows Server installs currently has to consider Windows Server Core, Windows Server Core with the AppCompatibility FoD and Windows Server with Desktop Experience. If Microsoft ever introduces an "AppCompatibilty FoD 2" as a further in-between choice, the package manifest spec should be able to support that too (keep it flexible/extensible)
Many community repo package authors will understandably forego testing compatibility with these 3 different deployment scenarios of Windows Server in all its various versions. Many if not most packages will therefore probably never have up-to-date compatibility metadata for Windows Server.
Automated pipelines could test whether the installation of a package succeeds on all these different Windows Server versions and configurations, but cannot assert the software functioning
Software being compatible with Server Core is not a simple yes/no checkbox. If software "A" only works partially, or maybe even doesn't open at all but the installer registered COM servers and DLLs which another software "B" depends on and CAN use successfully on Server Core then is software "A" compatible with Core or not?
winget should therefore never refuse to install any package, marked compatible/incompatible through its metadata or not, on any deployment-type of Windows Server. In the example above, if I want to install software "B" which is marked compatible with Server Core, and it depends on software "A" which technically isn't really compatible with Server Core but installs enough to satisfy the dependencies of software "B" then it would be really infuriating to have winget refuse to install it just because some community manifest author (understandably) didn't consider this usecase.
winget could print a warning though when installing packages that aren't explicitly marked as compatible with the installed flavor of Windows Server (Core / Core + FoD)
It's maybe possible to utilize the existing manifest metadata fields Platform and Dependencies.WindowsFeatures for a package to indicate compatibility with Server Core and/or Server Core with the AppCompatibility Feature.

@jantari was a long read but I agree with you in most parts. Also your reasons with or better said against whitelisting are very reasonable. Thanks for adding your valueable thoughts.
I strongly agree on the mixed environment of core and GUI install options and the adoption rate of winget.
Personally would like to focus on Windows Server 2025 as supported and 2022 as unsupported. 2019 is out of mainstream support and as such no hope, by definition, for any change or backport.

In general, I agree with what was stated. There may be some minor differences in my thinking currently.
Adding "allow" or "deny" lists in WinGet is something I'm currently opposed to. That kind of granularity comes with too much overhead. That's why we created the REST APIs, so enterprise customers could select which packages (and versions) they wanted to support in their own source. Of course, that means we have all kinds of interesting policies in the WinGet community repository, but the client was designed with many of these use cases in mind for future scenarios.
WinGet does have the "--force" argument, which is essentially giving users the ability to tell WinGet: "I don't really care what you think, or what the manifest says, just do what I told you. 😊"
Given that, I think having some kind of metadata in the manifest describing which target OS platform/versions a package has been tested or verified against is goodness. The client would essentially make determinations as it does today with respect to which installer it thinks is most appropriate for the device at the point in time the command is run. If no suitable match is found,  WinGet would report the results, but the user could simply force the "install"/"upgrade".
If an existing version of the package is present on the system, there are other implications to consider, but I agree. An administrator should be able to override the default behavior and manage packages how they see fit.
There are several dimensions evaluated when selecting an installer. I don't know if we need to extend the list, but I'm including it below for reference. I think extending "Target Platform" makes the most sense in the context of this discussion. I'm also thinking on Server without desktop experience, the default installation mode should be "silent".

Architecture (ARM64, x64, x86)
Installer Type (exe, MSI, MSIX, portable)
Locale (BCP 47)
Scope (User vs. Machine)
Target Platform (Windows.Desktop)

Hi @denelon would using the language value from this registry key be translatable to a locale?

Looking at ProcessMonitor, winget or a library used by it currently already queries PreferredUILanguages inside HKLM\System\CurrentControlSet\Control\MUI\Settings. This contains a BCP 47 language tag on my systems, and this key also exists on Server Core 2022 out of the box.
However I believe the problem with both these keys is that they show the machine locale and winget would probably rather use the current user's locale preference. Quickly searching through the current user's registry with reg query "HKCU" /f "en-US" /d /s on Server Core 2022 shows a few results too though:
HKEY_CURRENT_USER\Control Panel\Desktop\MuiCached
    MachinePreferredUILanguages    REG_MULTI_SZ    en-US

HKEY_CURRENT_USER\Control Panel\International
    LocaleName    REG_SZ    en-US

HKEY_CURRENT_USER\Control Panel\International\User Profile
    Languages    REG_MULTI_SZ    en-US

HKEY_CURRENT_USER\Control Panel\International\User Profile System Backup
    Languages    REG_MULTI_SZ    en-US

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\International
    AcceptLanguage    REG_SZ    en-US,en;q=0.5

There are probably more approved ways to get to this information too, because the International PowerShell module is pre-installed on Server Core 2022 and works. There's some good cmdlets in there (check Get-Command -Module International -Verb Get). This means we can successfully run cmdlets such as:

Get-WinSystemLocale
Get-WinHomeLocation
Get-WinUserLanguageList

I haven't debugged whether these call Core-compatible APIs or access the registry directly, but I'd expect sixteen layers of enterprisey factory-factories aka APIs so that should be good for winget.

Unrelated, I'll soon have some more details on the Server Core 2022 compatibility of winget. My original observations in February were somewhat flawed because I was working on a system I had already experimented on and tried lots of things prior so it turns out it's not JUST that one API call after all.

Update with additional observations regarding Server Core (2022) compatibility:
I have to make a late follow-up to this post; what I observed above isn't incorrect but I have just deployed a new, untouched Server 2022 Core and made some additional observations. The VM I had used for the troubleshooting above wasn't "clean" because I had already experimented a bunch trying to get winget to run, so here's my new (re-)discoveries:
winget depends on Windows.Globalization.dll. This library isn't present on Server Core 2022, you have to copy this file out of System32 from a machine with the Desktop Experience or with the AppCompatibility FoD installed and put it into your winget program directory next to winget.exe.
Just adding this file has already allowed winget on my new, vanilla Server 2022 Core VM to install some packages, however another package was still failing to install with the dreaded Class not registered error. I don't know exactly what exact code paths were taken here, but some troubleshooing revealed that the issue was caused by winget not understanding that an API it tried to use (Windows.System.UserProfile.GlobalizationPreferences) is actually also provided by the aforementioned Windows.Globalization.dll despite the namespaces not matching up. Winget kept trying to find Windows.System.UserProfile.dll, which I don't think is winget's fault but just default fallback behavior from Windows for DLL discovery.
On my GUI systems there's a registry key (HKLM\SOFTWARE\Microsoft\WindowsRuntime\ActivatableClassId\Windows.System.UserProfile.GlobalizationPreferences) that I believe is responsible for pointing apps to the correct DLL to use for that type (there's a DllPath key there that points to C:\Windows\System32\Windows.Globalization.dll), however I wasn't sure what kind of side-effects it would have to manually create this key on my Server Core system and I wasn't able to get it to appear naturally by running regsvr32.exe Windows.Globalization.dll, so what I ended up doing was creating a symlink in the winget program directory named Windows.System.UserProfile.dll that links to the Windows.Globalization.dll in the same location:

This workaround makes winget find the correct DLL it's looking for under the wrong name without having to edit global registry keys or system directories which could confuse and break other applications.
Now, interestingly, after applying these two fixes I currently do NOT need to set my locale preference using the winget settings.json file on this system to be able to install all the software I want. However I would still recommend performing all three fixes (copying over Windows.Globalization.dll, creating the symlink, setting the locale preference in settings.json) as they're harmless and winget goes through lots of different code paths during installations, calling locale/language APIs many different places and I've seen Class not registered failures related to that at many different stages of the install and show flows by now.


feat: stop ADO extension reliance on pipeline-installed Node and Yarn versions (by migrating to yarn v3)

Details
Leaving this as a draft pending feedback on design + testing as-deployed in a test extension
This PR migrates the repo to yarn v3, both for development of the extension and also for our customers. Notable impacts of this are:

A copy of yarn 3 is now checked into the repo
The same copy of yarn 3 is now bundled with the ADO extension and invoked directly. This means that users will no longer need to include any explicit npm install -g yarn step, and it insulates us from issues due to from differences in yarn versions based on customer environment.
Because of this above, it is easier to invoke our bundled yarn using the same node binary that our script runs within (the node 16 version guaranteed to exist on the agent regardless of user pipeline tasks). This means that users will no longer need to include any explicit NodeTools@0 step, and it insulates us from issues due to differences in Node versions based on customer environment (I suspect this should fix #1551).

This has the very significant downside of relying on the agent node version to be recent enough to support our task. That's true today, but we've had issues with that in the past - agents didn't add node16 support for tasks until well after we were having trouble with the previously-supported version being EOL and unsupported by many of our dependencies

We get to drop our lerna dependency in favor of the yarn workspaces plugin, which substantially reduces our overall dependency tree size
Pre-empts the possibility of package-squatting attacks against workspace-internal packages

Motivation

Removes a few steps from onboarding
Prevents several classes of errors we've seen customers hit recently
Enables more precise yarn resolutions
Pre-empts package-squatting attacks

Context
Reviewer note: Most of the individual changes are more or less mechanical and not super interesting. However, these three files are substantive changes to the way the extension functions and need deeper review:

packages/ado-extension/prepare-package-dir.js
packages/ado-extension/src/install-runtime-dependencies.ts
packages/shared/build-runtime-package-metadata.js

Some reference material I used while putting together this PR:

Service repo's yarn v3 migration PR for reference
Yarn's v1 -> v2+ migration guide that I followed for the first few commits

Pull request checklist

[x] Addresses an existing issue: Fixes #1109 and maybe also #1551
[n/a] Added relevant unit test for your changes. (yarn test)
[n/a] Verified code coverage for the changes made. Check coverage report at: <rootDir>/test-results/unit/coverage
[x] Ran precheckin (yarn precheckin)

@dbjorge Overall, I think this would be a big improvement to the onboarding flow!
A few small questions:

What does the maintenance of having yarn checked into the repo look like? Should we expect to update this periodically?
Curiosity question: I noticed that the package.json files now have added devDependencies, was that a result of switching from lerna to yarn 3?
I think this pull request could remove lerna.json at the root, correct?

What does the maintenance of having yarn checked into the repo look like? Should we expect to update this periodically?

Yes, we should expect to update this periodically, probably at a pace comparable to updating node versions we use.

Curiosity question: I noticed that the package.json files now have added devDependencies, was that a result of switching from lerna to yarn 3?

This is a result of yarn v2+ being more strict about importing/using dependencies that aren't explicitly listed. Particularly, yarn v2+ doesn't place entries in packages/subpackage/node_modules/.bin for devDependencies that aren't explicitly listed by the subpackage, which breaks most dev tools we use in practice.

I think this pull request could remove lerna.json at the root, correct?

Yep, good catch, will push an update.

Test run against 8e89098. Ran a matrix of test cases (all combinations of hosted agent images ubuntu-18.04, ubuntu-20.04, ubuntu-22.04, windows-2019, windows-2022 each with all combinations of "no explicit node/yarn install steps", "install node 16", "install node 16 + yarn", "install node 18"), all worked as expected.


Images need to be numbered starting at 1 not 0

This is not an issue up for debate. image number starts at 1 not 0. please fix this. thanks.

fixed.


Wuxmedia debian

I think this looks waay better

Looks really good. Will merge when I'm back at a computer.


[!] Release Flags for a Trojan file, on Windows Defender [!]

https://github.com/wheybags/EmperorLauncher/releases/download/v1.0/EmperorLauncher.v1.0.zip
=
/!\ TROJAN (Source: Windows Defender)

Yep, the things this program is doing look a lot like malware (detouring system DLLs). Not much I can do about this - I'm not gonna buy a codesigning key to make it go away. If you still feel uncomfortable, feel free to audit the source code and then build it yourself, unfortunately that's all I can offer :(


It would be better if it could support inject timezones into pods only namespaces with labels

For the most part, k8tz works great, but I get confused when I want pods under certain namespaces not to be timezone injected.
Hope to support inject the timezone into the pod only if the namespace has a label.

Hi @1121437613,
you can disable injection by default (--set injectAll=false) and then it will inject only to namespaces that have an explicit k8tz.io/inject: true annotation
helm upgrade --install k8tz k8tz/k8tz --set injectAll=false
kubectl annotate --overwrite namespace my-specific-namespace k8tz.io/inject=true

Hi @1121437613, k8tz injection is enabled by default, but you can add annotation to namespaces that you don't want to inject by default
kubectl annotate --overwrite namespace my-specific-namespace k8tz.io/inject=false

you can also disable injection by default (--set injectAll=false) and then it will inject only to namespaces that have an explicit k8tz.io/inject: true annotation
helm upgrade --install k8tz k8tz/k8tz --set injectAll=false
kubectl annotate --overwrite namespace my-specific-namespace k8tz.io/inject=true

you can also annotate a specific deployment
kubectl annotate --overwrite deployment my-specific-deployment k8tz.io/inject=true k8tz.io/timezone=Canada/Pacific

annotation on deployment is prior to annotation on namespace, and namespace annotations are prior to values provided to helm (--set) you can play with those levels of configurations to achieve the best setup for you

Thank you for your reply, it solved my problem.

kubectl annotate --overwrite deployment my-specific-deployment k8tz.io/inject=false

I tried to prevent injection with annotations k8tz.io/inject=true and k8tz.io/timezone=UTC but nothing works
k8s version 1.24.3
k8tz version 0.7.0
I tried copying the deployment to a different namespace, but it didn't work

my bad, it was a copy error
k8tz.io/inject=false  does nothing

Thanks！it worked！


Unused parameters fix

This is kinda hack to make vulture happy with your code ;) The problem is that unused parameters are seen as unused vars in AST and vulture ignores any #pylint #noqa etc. specifiers

@tisnik Your image is available in the registry: docker pull MISSING_REGISTRY_NAME/MISSING_IMAGE_NAME:SNAPSHOT-PR-28

Great and goo to know! Thanks @tisnik .. I'll make sure I apply the approach to the future code as well.
LGTM, merging ;)


[GSB] Add verification of all generic signatures within a module.

Add a verification pass to ensure that all of the generic signatures in
a module are both minimal and canonical. The approach taken is quite
direct: for every (canonical) generic signature in the module, try
removing a single requirement and forming a new generic signature from
the result. If that new generic signature that provide the removed
requirement, then the original signature was not minimal.
Also canonicalize each resulting signature, to ensure that it meets the
requirements for a canonical signature.
Add a test to ensure that all of the generic signatures in the Swift
module are minimal and canonical, since they are ABI.

Resolves SR-3733 / rdar://problem/31412994

@swift-ci please smoke test and merge


[AdminServer Error] failed to get capacity: no such file or directory

When i get into the "Projects",  got an error like this
"We are unable to perform your action because internal server errors have occurred."
1)Version of docker engine and docker-compose.
root@l-192168017202-docker:~# docker version
Client:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   78d1802
 Built:        Tue Jan 31 23:35:14 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.2
 Git commit:   78d1802
 Built:        Tue Jan 31 23:35:14 2017
 OS/Arch:      linux/amd64

2) harbor.cfg
hostname = indexdev.cloud.com
ui_url_protocol = https
db_password = eId8u39YVzPA
max_job_workers = 3
customize_crt = on
ssl_cert = /root/a/server.crt
ssl_cert_key = /root/a/server.key
secretkey_path = /data
admiral_url = NA
clair_db_password = password
email_identity =
email_server = smtp.mydomain.com
email_server_port = 25
email_username =<EMAIL_ADDRESS>email_password = abc
email_from = admin<EMAIL_ADDRESS>email_ssl = false
harbor_admin_password = Harbor12345
auth_mode = db_auth
ldap_url = ldaps://ldap.mydomain.com
ldap_basedn = ou=people,dc=mydomain,dc=com
ldap_uid = uid
ldap_scope = 3
ldap_timeout = 5
self_registration = on
token_expiration = 30
project_creation_restriction = everyone
verify_remote_cert = on

3) adminserver logs
<IP_ADDRESS> - - [10/Oct/2017:16:10:38 +0000] "GET /api/configurations HTTP/1.1" 200 958
<IP_ADDRESS> - - [10/Oct/2017:16:10:40 +0000] "GET /api/configurations HTTP/1.1" 200 958
2017-10-10T16:10:40Z [ERROR] [systeminfo.go:28]: failed to get capacity: no such file or directory
<IP_ADDRESS> - - [10/Oct/2017:16:10:40 +0000] "GET /api/systeminfo/capacity HTTP/1.1" 500 22
<IP_ADDRESS> - - [10/Oct/2017:16:13:34 +0000] "GET /api/configurations HTTP/1.1" 200 958
<IP_ADDRESS> - - [10/Oct/2017:16:13:35 +0000] "GET /api/configurations HTTP/1.1" 200 958
2017-10-10T16:13:35Z [ERROR] [systeminfo.go:28]: failed to get capacity: no such file or directory
<IP_ADDRESS> - - [10/Oct/2017:16:13:35 +0000] "GET /api/systeminfo/capacity HTTP/1.1" 500 22
<IP_ADDRESS> - - [10/Oct/2017:16:14:14 +0000] "GET /api/configurations HTTP/1.1" 200 958
<IP_ADDRESS> - - [10/Oct/2017:16:14:15 +0000] "GET /api/configurations HTTP/1.1" 200 958
2017-10-10T16:14:16Z [ERROR] [systeminfo.go:28]: failed to get capacity: no such file or directory
<IP_ADDRESS> - - [10/Oct/2017:16:14:16 +0000] "GET /api/systeminfo/capacity HTTP/1.1" 500 22

What it [systeminfo.go:28]: failed to get capacity: no such file or directory means?

I have solved this problem.There 's a little problem need to change.
The pvc `registry-pvc` is **required by** adminserver.
2017-10-10T16:14:16Z [ERROR] [systeminfo.go:28]: failed to get capacity: no such file or directory

harbor/make/kubernetes/adminserver/adminserver.rc.yaml
spec:
  template:
    spec:
      containers:
        name: adminserver-app
        volumeMounts:
        - mountPath: "/data"
          name: storage
      volumes:
      - name: storage
        persistentVolumeClaim:
          claimName: registry-pvc

thx, i 've  solved this problem

Discussed with @reasonerjt. When the IMAGE_STORE_PATH directory doesn't exist, print a warning for "failed to get capacity: no such file or directory" and return 0 as the storage capacity. So it won't break when using S3/GCS as the registry storage.


⚠ Samsung has degraded performance

In c6b3a54, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 3057 ms

Resolved: Samsung performance has improved in cd21f75.


[arquillian/arquillian-extension-liferay#13] Rename Extension

Just started reviewing :) :octocat: Sent from GH.

Merged... thx you!


StatusRuntimeException: UNAUTHENTICATED error

when i start my app, i get this error message.
where can i get a license key? is it different from api-key in scavenger.conf file?
2023-02-28 20:17:22.675  INFO 38534 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] polling dynamic config
2023-02-28 20:17:22.679  INFO 38534 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] trying to resolve collector url by accessing http://localhost:8080/javaagent/v5/initConfig
2023-02-28 20:17:24.158  INFO 38534 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] resolved collector url is localhost:8080
2023-02-28 20:17:24.158  INFO 38534 --- [enger scheduler] c.n.s.javaagent.publishing.GrpcClient    : [scavenger] creating new grpc client. host is localhost:8080
2023-02-28 20:17:25.241 ERROR 38534 --- [enger scheduler] c.n.s.javaagent.scheduling.Scheduler     : [scavenger] poll config failed

sc.io.grpc.StatusRuntimeException: UNAUTHENTICATED
	at sc.io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:271) ~[scavenger-agent-java-1.0.3.jar:1.0.3]
	at sc.io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:252) ~[scavenger-agent-java-1.0.3.jar:1.0.3]
	at sc.io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:165) ~[scavenger-agent-java-1.0.3.jar:1.0.3]

@umyonghyun UNAUTHENTICATED is an exception that occurs because the API key is not valid.
The API key can be found via the UI.
First, please follow the two guides below.

Create a workspace
Create a configuration file

@taeyeon-Kim, thanks for explanation.
However I followed the guide.
I created a scavenger's configuration file in the scavenger dashboard and used the created api key.

however when I started my app, the above UNAUTHENTICATED error occurred.
2023-03-01 22:15:59.753  INFO 7027 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] polling dynamic config
2023-03-01 22:15:59.757  INFO 7027 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] trying to resolve collector url by accessing http://localhost:8080/javaagent/v5/initConfig
2023-03-01 22:16:00.107  INFO 7027 --- [enger scheduler] c.n.s.javaagent.publishing.Publisher     : [scavenger] resolved collector url is localhost:8080
2023-03-01 22:16:00.107  INFO 7027 --- [enger scheduler] c.n.s.javaagent.publishing.GrpcClient    : [scavenger] creating new grpc client. host is localhost:8080
2023-03-01 22:16:00.273 ERROR 7027 --- [enger scheduler] c.n.s.javaagent.scheduling.Scheduler     : [scavenger] poll config failed

sc.io.grpc.StatusRuntimeException: UNAUTHENTICATED
	at sc.io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:271)
	at sc.io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:252)
	at sc.io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:165)
	at sc.com.navercorp.scavenger.model.GrpcAgentServiceGrpc$GrpcAgentServiceBlockingStub.pollConfig(GrpcAgentServiceGrpc.java:263)

this is scanvenger collector server's log.
[armeria-common-blocking-tasks-1-3] INFO  c.n.s.controller.AgentController - init config requested from grpc client <IP_ADDRESS> with licenseKey: b6dfb431-5205-442b-af29-29dee1e36090
I wonder if there's something I'm missing.

@umyonghyun How did you run your collector and API?

@taeyeon-Kim
I download jar file from the provided repository (https://github.com/naver/scavenger/releases)
and ran the jar file in my local like this.
Collector : java -jar scavenger-collector-boot-1.0.3.jar
API : java -Dscavenger.collector-server-url=http://localhost:8080 -jar scavenger-api-boot-1.0.3.jar

@umyonghyun
The collector and api have a default profile of local, which means they each use in-memory h2.
This means that there is no data sharing between the two modules.
Please run it like below.

collector: java -Dspring.profiles.active=h2 -jar scavenger-collector-boot.jar
api: java -Dscavenger.collector-server-url=http://localhost:8080 -Dspring.profiles.active=h2 -jar scavenger-api-boot.jar

@taeyeon-Kim , I understand the situation that was the  issue. Thank you for the explanation.
collector and api must share the same repository.
It would be easier to understand if the overall architecture picture was attached to the manual.

@kojandy Hey. It's time to publish HelloWorld article. I was afraid of the case like this. :-)