[RFC] Aliases for migrations

Migrations names can't be changed after release, because it will break any installation that already applied them. This means that:

you can never fix typo in migration name,
you can not migrate from non-namespaced migrations to namespaced migrations,
if you already use namespaced migration, you can never change namespace of your project or change structure of directories that can affect migrations namespaces.

Basically, migrations can be really PITA for long-term projects, especially if you decide to use namespaced migrations.
I propose to add new static property to yii\console\Migration:

namespace yii\log\migrations;

use yii\db\Migration;

class M141106185632LogInit extends Migration
{
    public static $aliases = [
        'm141106_185632_log_init', // old non-namespaced migrations
        'yii\log\migrations\M141106185632LogInt', // typo
    ];

    // ...
}

On migration/up

Check if any of migration aliases are already present in migration history.
If it is present - add current migration and all non-applied aliases to migration history with current timestamp and some prefix for name (like -), without running up() method.
If it's not applied - run up(), add migration (without prefix for name) and all aliases (with prefix) to history with current timestamp.

On migrate/down

Pick last applied migration from history.
If name of this migration is prefixed - remove from history without running down(). Back to step 1. (removing prefixed migration from history should not count as revert).
If migration does not have alias prefix in history - run down(), remove migration from history, and all related aliases (so if we're reverting m141106_185632_log_init we should also remove yii\log\migrations\M141106185632LogInit and yii\log\migrations\M141106185632LogInt from history).

Tricky part
The obvious problem is finding real migration class for an alias (if we're reverting m141106_185632_log_init we need actually revert yii\log\migrations\M141106185632LogInit). In the worst case we could scan all migrations and use $aliases values to create alias => real-class map. But usually we could avoid this - in most cases we first load a real class, so we could start building map from already loaded migrations and do a full scan only if migration to revert can not be found.

Overall it complicates migrations significantly while the benefit isn't as significant.
Indeed, migration name could not be adjusted but that's fine. That's the nature of it.

In that case using namespaced migrations does not make any sense in most cases - you just can't do anything with it. Non-namespaced migrations can be moved to different directory, and after config adjustment their works fine. But you can't do the same for namespaced migration, since it affects namespace. This limits refactoring a lot.
AFAIK you have a plans to change current non-namespaced migrations shipped with Yii (like m141106_185632_log_init) to namespaced ones (like yii\log\migrations\M141106185632LogInit). This will introduce massive BC break which is nearly impossible to fix in app code.

Why would you refactor placements of migrations?

This is side effect of project refactoring. I keep migrations in modules, and sometimes I need to remove or rename module, so I need also move migrations. I can do this only because I don't use namespaces in migrations, but I still can't fix any typo in migration name.

I didn't think about this aspect of namespaced migrations... @klimov-paul what do you think?

I'm giving my +1 to this issue. I use yii2 to build an on-prem solution for my customers, meaning we install our app on their servers, and they run the migrations. The current setup makes it hard to both support existing applications and new installs when there can be bugs in the migrations related to both. We experimented with writing our own plugin system so that we can enable/disable features for customers who don't need them or aren't paying for them yet, and that includes conditionally loading some migrations. That means the ordering isn't consistent across all our installs, because the plugins might be enabled from the start, where they'll just be naturally ordered by date, but also if the plugin is enabled after the fact, it'll have the migrations from the plugin ordered at the end. That sort of use-case doesn't seem well covered in the current migration system, so any features to help ease that would be greatly appreciated. Currently I still use migrationPath and not migrationNamespaces, and I don't see an easy way to transition when the path/namespace is pretty much locked in place because of how migrations work right now. Aliasing seems like a decent solution for that.

You still can do a migration that updates migrations table replacing namespace part but yes, that's a bit hackish.

I can not see a problem with moving namespaced migrations to another directory: in order to make it work all you need to setup a path alias equal to migration namespace to another folder:
Yii::setAlias('@app/migrations', '/path/to/project/new/migrations/path');

@klimov-paul You can't move single migration in this way. It is also more like a hack - your migrations namespace is out of sync with directory structure.

And just how putting aliases into migration class is better?
This 'hack' as you call it - is a basics of class autoloading. Similar hacks are used to replace standard helpers (like Inflector) with custom ones.

Example of changing namespace in migrations: https://github.com/yiisoft/yii2-queue/commit/9edb0a052b5a21056cf624f19815b05dc431b2a5#diff-035fdbf9bbbbf357e2eeeeee4f737f4f

Midifaction of the migration history is just the same matter as modification of the GIT history.
Taking about changing particular migration name is the same as changing comment for the GIT commit.
While such changes are possible - they break any existing working copy of the project after being made.
Being published migrations can not adjusted any further as well as published GIT commits can not be modified (squash, hard reset, comment modifications etc.).
You need to keep your migration intact after they being published and can be picked up by other working copies. If you wish to modify them afterwards - you will have to deal with consiqvences on your own.

Using namespace in migrations you can adjust the path alias to it and move them under different folder, so this feature of non-namespace migration is actually intact. It allows you to restructurize your codem while keeping migration history intact.

I don't want to modify my migrations history, I want to modify code of my application (including migrations). I already proposed  solution for this with keeping history intact (none of the existing entries in migration table are modified or removed). And your answer is:

You don't need it because migrations should never change. But we already did it and we are going to do it again.

I don't want to modify my migrations history, I want to modify code of my application (including migrations)

That is the same thing: any modfications of the migrations source is a BC break over any other project working copy. You can not add, for example, extra index to some migration.

I already proposed solution for this with keeping history intact (none of the existing entries in migration table are modified or removed)

Your solution requires loading ALL migration classes source codes at once per each migration operation (up, down, history, new and so on) - otherwise it can not function. This will cause a huge performance degradation especially for the long-live projects.

And your answer is: You don't need it because migrations should never change.

My answer is you can move migrations directory to another place you like https://github.com/yiisoft/yii2/issues/14481#issuecomment-316672352
My point is the solution is already exists.
You can also use 2 different namespaces: one for 'legacy' migrations and another - for the new ones (let is if you like to do so) and combine them under single config at single command without breaking anything.
I can not see absolutely no necessity to rename existing migration in the project, and I see absolutely no reason to introduce a huge twisted codebase in order to support it.
I understand you wish to keep your code clean, but keeping those $aliases does not look clean either.

But we already did it and we are going to do it again.

First of all we did nothing yet: #13141 is not merged, while actions of mister @zhuravljov are beyond the reach of @yiisoft. If you have a concern about his commit - you should contact him instead.
However, I should admit that future of code built-in migrations is questionable and at some point thier modifications or thier removal will be inevitable. That is why I always against introduction and usage of external migrations in the code. Still so far I am unable to convince the rest of the team on this matter, so it is for them to decide what to do here.

That is the same thing: any modfications of the migrations source is a BC break over any other project working copy.

No, it's not. It is BC break only when I change migration logic. Changing name of migration does not change it's logic - it will work exactly the same as before change. And sometimes you actually must edit old migrations, to make it compatible with new version of framework or PHP.

Your solution requires loading ALL migration classes source codes at once per each migration operation (up, down, history, new and so on) - otherwise it can not function.

You are wrong again. You never need to load all migrations on migrate/up. You may need this on migrate/down but only in some particular case (for example if you're reverting migrations step by step and revert alias without reverting real migration). And you probably will never need to load all migrations - you need  load only non-applied.
But if this is still a problem for you, I'm sure that this could be optimized.

You are wrong again. You never need to load all migrations on migrate/up

Is that so?
Consider following I rename migration m...Legacy to m...New and according to your solution I put m...Legacy into m...New::$aliases. Thus in my history there is m...Legacy but there is no m...New.
When I run migration/up all files under migration path will be picked up including m...New and only after it is loaded we can find out is is already present in the history after resolving $aliases.
In case you are moving several hundreds migrations from one namespace to another one as you want here - all those migrations will be loaded on migration/up before they can be recognized as already applied.

It works in the same way as installing app from scratch - if you have 1k migrations, first installation will load them all and run. But it will not load unchanged migrations.

So you propose to save both migration legacy name (alias) and new name in the history doubling the entries in the history table?

Yes.

In that case how history reverting (migrate/down) should work if same migration is mentioned several times there?
Besides It is better to create a separated command or console command behavior, which will just iterate migration history replacing old names with new ones.

In that case how history reverting (migrate/down) should work if same migration is mentioned several times there?

It is explained in first post - did you read it?

Besides It is better to create a separated command or console command behavior, which will just iterate migration history replacing old names with new ones.

And how it is supposed to be better? It looks event more complicated to implement and definitely less convenient for end user (he should always run two commands except one for database update?).

And how it is supposed to be better? It looks event more complicated to implement and definitely less convenient for end user (he should always run two commands except one for database update?).

???
Here is an implementation:
<?php

namespace yii\filters;

use yii\base\ActionFilter;
use yii\console\controllers\MigrateController;
use yii\db\Connection;
use yii\db\Query;
use yii\di\Instance;

/**
 * ```php
 * return [
 *     'controllerMap' => [
 *         'migrate' => [
 *             'class' => 'yii\console\controllers\MigrateController',
 *             'as versionReplacer' => [
 *                 'class' => 'yii\filters\AdjustHistoryFilter',
 *                 'versionReplaces' => [
 *                     'm140506_102106_rbac_init' => 'yii\rbac\M140506102106RbacInit',
 *                 ],
 *             ],
 *             'migrationNamespaces' => [
 *                 'app\migrations',
 *                 'some\extension\migrations',
 *             ],
 *         ],
 *     ],
 * ];
 * ```
 */
class AdjustHistoryFilter extends ActionFilter
{
    /**
     * @var array versions to be replaced in format: `[legacyVersion => newVersion]`, for example:
     *
     * ```php
     * [
     *     'm140506_102106_rbac_init' => 'yii\rbac\M140506102106RbacInit',
     * ]
     * ```
     */
    public $versionReplaces = [];

    /**
     * @inheritdoc
     */
    public function beforeAction($action)
    {
        if ($action->id === 'create') {
            return true;
        }

        /* @var $migrateController MigrateController */
        $migrateController = $action->controller;
        $migrateController->migrationTable;

        Instance::ensure($migrateController->db, Connection::className());

        $legacyVersions = array_keys($this->versionReplaces);

        $existingLegacyVersions = (new Query())
            ->select(['version'])
            ->from($migrateController->migrationTable)
            ->andWhere(['in', 'version', $legacyVersions])
            ->column($migrateController->db);

        if (empty($existingLegacyVersions)) {
            return true;
        }

        foreach ($existingLegacyVersions as $legacyVersion) {
            $newVersion = $this->versionReplaces[$legacyVersion];
            $migrateController->db->createCommand()
                ->update($migrateController->migrationTable, ['version' => $newVersion], ['version' => $legacyVersion])
                ->execute();
        }

        return true;
    }
}

It will adjust migration history automatically on any migrate command execution.

Your implementation does not support reverting.
It need to be manually configured by the end user - it is useless for extensions/modules authors.
It actually modifies migration history, and AFAIK you're against this (see https://github.com/yiisoft/yii2/issues/14481#issuecomment-316681665).

Personally I solved this problem using a @klimov-paul's way. But yes, it would be nice to refactor class names/namespaces without all these tricks. And I don't see a clean way beside an UUID usage in each migration.

Your implementation does not support reverting.

Reverting of what?

It need to be manually configured by the end user - it is useless for extensions/modules authors.

I think it is much more reliable.
So you suppose that extension author should be first of all concern about your project built on his extension. So he has no right to having a clean code without legacy class names - this is only yours priveledge. If I a author of the extension and I wish to rename some migration class I should provide an alias to the old migration name inside it, while regulary such things are handled via UPGRADE notes.
And if I use some extension, which has some migration renamed I should enforce its author to provide these aliases even if he values his clean code. I suppose I should hunt him down and turture him until he agrees or something.
While picking up any external code you are doing it on your own risk. And external library breaks a BC, including migration renaming - it should provide UPGRADE note, which you should apply on your own.

It actually modifies migration history

That is exactly what this issue is about! Migration class name IS A PART OF THE HISTORY as it serves as version ID. Modification of the migration class name means necessity of modification of the history.
Renaming migration is the same thing as renaming GIT commit changing its original hash to some other pretty one. While technically it is possible - it breaks the history.
Migrations are not ordinally classes, which can be manipulated as you like - they are special are require special treatment.

Migration class name IS A PART OF THE HISTORY as it serves as version ID.
So a version ID should not depend on this in 2.1. Probably…

So a version ID should not depend on this in 2.1

This is unlikely to be possible as program should be able to find migration source using its ID.
The only working solution based on such approach will be creating a manual map for migration locations to thier ID somewhere in migration config, like following:
return [
    'controllerMap' => [
        'migrate' => [
            'class' => 'yii\console\controllers\MigrateController',
            'versions' => [
                'abcdef12341' => 'app\migrations\M1',
                'abcdef12342' => 'app\migrations\M2',
                'abcdef12343' => 'yii\rbac\migrations\rbac_init',
                ...,
            ],
        ],
    ],
];

Then history table will contain only UIDs, but this require registering every migration in the versions map.
However in general versions map can be generated on the fly, while picking up new migrations, and then be adjusted at will. But still it looks like overcomplecating things.

Reverting of what?

Migrations. If I upgrade some module from 1.x to 2.x (which changes migrations names), apply migrations and find some regressions, I want to go back to 1.x. Normally I revert migrations, revert to 1.x version of module and I should have a state before whole changes. This is not the case with your solution.

So you suppose that extension author should be first of all concern about your project built on his extension. So he has no right to having a clean code without legacy class names - this is only yours priveledge. If I a author of the extension and I wish to rename some migration class I should provide an alias to the old migration name inside it, while regulary such things are handled via UPGRADE notes.

Thats because framework does not provide any tools for such situations.That does not mean that it always has to be in this way - if there is a way to improve this, why don't do this?

That is exactly what this issue is about! Migration class name IS A PART OF THE HISTORY as it serves as version ID.

Migrations history is in migration table. Migration class is not a migration history, it is only class with some code, and real migration history (in migration table) only referencing it. If we have mechanism for finding this code even after renaming migration class, which keeps all old entries in migration table intact, then there is no modification of existing history of migrations.

So you suppose that extension author should be first of all concern about your project built on his extension. So he has no right to having a clean code without legacy class names - this is only yours priveledge. If I a author of the extension and I wish to rename some migration class I should provide an alias to the old migration name inside it, while regulary such things are handled via UPGRADE notes.

Alternative if we keep this, there should be explicit note in documentation, that modules/extensions consumer should never load migrations directly from module/extension. So basically he should never do something like this:
yii migrate --migrationPath=@yii/rbac/migrations/

Source: http://www.yiiframework.com/doc-2.0/yii-rbac-dbmanager.html
He should create own migration that extends migrations provided with framework/extension/module and add new migrations manually on every composer update

@klimov-paul I do agree with you. And yes, the solution you proposed is what I'm thinking about: an id to class map & a migration map scanner/builder.
For existing migrations we can suppose their ids equal to their class names so if someone wants to refactor the migrations it would be required to set (for example) $id to match an existing history entry.
The only problems I see ATM are 1) a scanner/builder performance 2) if we really need all of this.

I just want to point out how Laravel does migrations, it's worth discussing the differences to see what good ideas they might have implemented to help improve migrations in Yii
https://laravel.com/docs/5.4/migrations
https://laravel.com/docs/5.4/packages#migrations

Laravel's Migrator builds a list of files in all specified directories and uses a file name as a migration name and a class name. Similar to Yii but a different implementation. No namespaces, no refactorings, no problems.

BTW Phinx works similar to the comment: it loads all migration classes and uses a getVersion(): float method to sort them. Versions are assumed to be microtome() and by default they are extracted from file names.
Looks good and should be simple enough to implement.
It even could be auto migrated without any BC break as far as I see.

Yes, that could be a solution.


[Leetcode]: Minimum Difference Between Largest and Smallest Value in Three Moves

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
i want to add solution for above under leetcode-solution section.
Use Case
I will provide proper description and comments.
Benefits
No response
Add ScreenShots
No response
Priority
Medium
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@manishh12 do not open more than 4 issue at a time
it's Spam

@Yashgabani845 okay will take care from next time

@manishh12  you cannot open a new issue today because you currently have four open issues. Please ensure a clean and organized environment and avoid creating spam. This project is part of GSSoc'24, which has strict rules, so it is important to follow all instructions.


feat(Slider): add Slider && SliderWithLine

Description
New slider styles.
Type of change
Please select the relevant option.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

typing 详见 https://github.com/tuya/DefinitelyTyped/commit/a6803228d812a5dc663358d435a8dc262f1355a7

@ZengBeauty 收到，我跑一下 example 就合掉！

Codecov Report

Merging #80 (00c964f) into master (2efd75f) will decrease coverage by 0.11%.
The diff coverage is 90.90%.

@@            Coverage Diff             @@
##           master      #80      +/-   ##
==========================================
- Coverage   90.91%   90.79%   -0.12%
==========================================
  Files         145      145
  Lines        7243     7323      +80
  Branches     1970     2032      +62
==========================================
+ Hits         6585     6649      +64
- Misses        530      546      +16
  Partials      128      128

Impacted Files
Coverage Δ

src/components/slider/slider.js
92.17% <82.45%> (-2.34%)
:arrow_down:

src/components/slider-with-line/index.js
95.55% <95.87%> (-4.45%)
:arrow_down:

Continue to review full report at Codecov.

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


pluginslist - schema missing

@idanl21 @swoehrl-mw ;
as per #201 , Tried installing plugins by mentioning list under spec.general section for latest version of operator ( 2.02, 2.03), and all version says not supported in schema, is this a bug ? I also looked at the crd file that is applied by helm chart and plugins list field is missing, is this a bug in helm chart ?
OpenSearchCluster/opensearch-operator/devops-cluster dry-run failed, error: failed to create typed patch object: .spec.general.pluginsList: field not declared in schema...
general:
    serviceName: devops-cluster
    version: 1.3.1
    pluginsList: ["repository-s3","https://github.com/aiven/prometheus-exporter-plugin-for-opensearch/releases/download/<IP_ADDRESS>/prometheus-exporter-<IP_ADDRESS>.zip"]

Looks like the pluginsList field is missing from crd template file under spec.general :

Added PR #250  to add these fields in crd template file .
please review

Fixed with PR #250


Hadoop 17853. ABFS: Enable optional store connectivity over azure specific protocol for data egress

This commit provides an option to enable store access on read path over an Azure specific protocol. To enable the feature, config "fs.azure.fastpath.enable"needs to be turned on. This will only work on Azure VMs and hence will be disabled by default.
With feature on, read requests will switch from HttpConnection to FastpathConnection. This will route the requests to APIs exposed by a new dependent artifact azure-storage-fastpath.
Feature flow: ABFS InputStream needs to cache a session token that it fetches from store backend, renew it close to its expiry and use it as an input to the API calls of artifact azure-storage-fastpath. On init, the inputStream needs to call upon the Open API to fetch file handle and use for the successive read calls. On inputStream close, the file handle created earlier needs to be closed too.
To unit test and inject failures, mock child classes of AzureBlobFileSystemStore, AbfsClient, AbfsRestOperation, AbfsInputStream are created in tests which mimic the instances/field values to test the feature even though the config is off. Existing test methods that do valid read tests are triggered seperately over mockFastpath mode to isolate test results from the existing tests.
The dependent artifact azure-storage-fastpath is a published artifact to public maven repository.

Test results:
HNS-OAuth
[INFO] Results:
[INFO]
[WARNING] Tests run: 110, Failures: 0, Errors: 0, Skipped: 1
[INFO] Results:
[INFO]
[WARNING] Tests run: 626, Failures: 0, Errors: 0, Skipped: 101
[INFO] Results:
[INFO]
[WARNING] Tests run: 288, Failures: 0, Errors: 0, Skipped: 52
HNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 110, Failures: 0, Errors: 0, Skipped: 7
[INFO] Results:
[INFO]
[WARNING] Tests run: 626, Failures: 0, Errors: 0, Skipped: 137
[INFO] Results:
[INFO]
[WARNING] Tests run: 287, Failures: 0, Errors: 0, Skipped: 68
NonHNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 110, Failures: 0, Errors: 0, Skipped: 7
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAzureBlobFileSystemCheckAccess.testCheckAccessForAccountWithoutNS:181 Expecting org.apache.hadoop.security.AccessControlException with text "This request is not authorized to perform this operation using this permission.", 403 but got : "void"
[INFO]
[ERROR] Tests run: 626, Failures: 1, Errors: 0, Skipped: 346
[INFO] Results:
[INFO]
[WARNING] Tests run: 287, Failures: 0, Errors: 0, Skipped: 68
AppendBlob-HNS-OAuth
[INFO] Results:
[INFO]
[WARNING] Tests run: 110, Failures: 0, Errors: 0, Skipped: 1
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemFlush.testWriteHeavyBytesToFileAsyncFlush:252 TestTimedOut
[ERROR]   ITestAzureBlobFileSystemFlush.testWriteHeavyBytesToFileSyncFlush:204 » TestTimedOut
[ERROR]   ITestAzureBlobFileSystemLease.testTwoWritersCreateAppendNoInfiniteLease:178->twoWriters:166 » IO
[INFO]
[ERROR] Tests run: 626, Failures: 0, Errors: 3, Skipped: 101
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemE2EScale.testWriteHeavyBytesToFileAcrossThreads:80 » TestTimedOut
[INFO]
[ERROR] Tests run: 288, Failures: 0, Errors: 1, Skipped: 100
Test failure observed in NonHNS-SharedKey: ITestAzureBlobFileSystemCheckAccess.testCheckAccessForAccountWithoutNS
is fixed as part of https://issues.apache.org/jira/browse/HADOOP-17767
Test failure observed in AppendBlob-HNS-OAuth:  ITestAzureBlobFileSystemLease.testTwoWritersCreateAppendNoInfiniteLease
will be fixed as part of https://issues.apache.org/jira/browse/HADOOP-17590
3 tests that failed with timeout is transient and pass on rerun.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  2s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 41 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 47s

trunk passed

+1 :green_heart:
compile
0m 38s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 31s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 24s

trunk passed

+1 :green_heart:
mvnsite
0m 37s

trunk passed

+1 :green_heart:
javadoc
0m 29s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 27s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  0s

trunk passed

+1 :green_heart:
shadedclient
16m 35s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
16m 54s

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

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 20s
/patch-mvninstall-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

-1 :x:
compile
0m 18s
/patch-compile-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-azure in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
javac
0m 18s
/patch-compile-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-azure in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
compile
0m 17s
/patch-compile-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-azure in the patch failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

-1 :x:
javac
0m 17s
/patch-compile-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-azure in the patch failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 18s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 239 new + 15 unchanged - 4 fixed = 254 total (was 19)

-1 :x:
mvnsite
0m 19s
/patch-mvnsite-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

-1 :x:
javadoc
0m 22s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
javadoc
0m 20s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
spotbugs
0m 17s
/patch-spotbugs-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
shadedclient
17m 21s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 20s
/patch-unit-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

-1 :x:
asflicense
0m 28s
/results-asflicense.txt
The patch generated 1 ASF License warnings.

76m 49s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/1/artifact/out/Dockerfile

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

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

uname
Linux 4333b6037f56 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 1c36140c594176bb8073db8774931cc2132949eb

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/1/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 41 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 56s

trunk passed

+1 :green_heart:
compile
0m 49s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 38s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 29s

trunk passed

+1 :green_heart:
mvnsite
0m 44s

trunk passed

+1 :green_heart:
javadoc
0m 35s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 32s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  7s

trunk passed

+1 :green_heart:
shadedclient
16m 52s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
17m 18s

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

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 23s
/patch-mvninstall-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

-1 :x:
compile
0m 22s
/patch-compile-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-azure in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
javac
0m 22s
/patch-compile-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-azure in the patch failed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.

-1 :x:
compile
0m 20s
/patch-compile-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-azure in the patch failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

-1 :x:
javac
0m 20s
/patch-compile-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-azure in the patch failed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 22s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 239 new + 15 unchanged - 4 fixed = 254 total (was 19)

-1 :x:
mvnsite
0m 21s
/patch-mvnsite-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

-1 :x:
javadoc
0m 22s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
javadoc
0m 23s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
spotbugs
0m 20s
/patch-spotbugs-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
shadedclient
17m  1s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 24s
/patch-unit-hadoop-tools_hadoop-azure.txt
hadoop-azure in the patch failed.

+1 :green_heart:
asflicense
0m 35s

The patch does not generate ASF License warnings.

78m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/2/artifact/out/Dockerfile

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

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

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 59a846d477b85e81737c20d3531deb4690d9874c

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/2/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 55s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  2s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 41 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m  6s

trunk passed

+1 :green_heart:
compile
0m 40s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 37s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 30s

trunk passed

+1 :green_heart:
mvnsite
0m 41s

trunk passed

+1 :green_heart:
javadoc
0m 34s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 31s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  1s

trunk passed

+1 :green_heart:
shadedclient
14m 46s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
15m  4s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 35s

the patch passed

+1 :green_heart:
compile
0m 33s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 33s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 3 new + 24 unchanged - 2 fixed = 27 total (was 26)

+1 :green_heart:
compile
0m 29s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 29s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 2 new + 19 unchanged - 1 fixed = 21 total (was 20)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 20s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 240 new + 15 unchanged - 4 fixed = 255 total (was 19)

+1 :green_heart:
mvnsite
0m 32s

the patch passed

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

-1 :x:
javadoc
0m 24s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
javadoc
0m 21s
/results-javadoc-javadoc-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 3 new + 15 unchanged - 0 fixed = 18 total (was 15)

-1 :x:
spotbugs
1m  9s
/new-spotbugs-hadoop-tools_hadoop-azure.html
hadoop-tools/hadoop-azure generated 14 new + 0 unchanged - 0 fixed = 14 total (was 0)

+1 :green_heart:
shadedclient
14m  4s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1m 55s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 32s

The patch does not generate ASF License warnings.

73m 46s

Reason
Tests

SpotBugs
module:hadoop-tools/hadoop-azure

Dead store to sasTokenForReuse in org.apache.hadoop.fs.azurebfs.services.AbfsClient.fastPathClose(String, String, AbfsFastpathSessionInfo, TracingContext)  At AbfsClient.java:org.apache.hadoop.fs.azurebfs.services.AbfsClient.fastPathClose(String, String, AbfsFastpathSessionInfo, TracingContext)  At AbfsClient.java:[line 802]

Dead store to sasTokenForReuse in org.apache.hadoop.fs.azurebfs.services.AbfsClient.fastPathOpen(String, String, AbfsFastpathSessionInfo, TracingContext)  At AbfsClient.java:org.apache.hadoop.fs.azurebfs.services.AbfsClient.fastPathOpen(String, String, AbfsFastpathSessionInfo, TracingContext)  At AbfsClient.java:[line 785]

Boxing/unboxing to parse a primitive new org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection(AbfsRestOperationType, URL, String, AuthType, String, List, AbfsFastpathSessionInfo)  At AbfsFastpathConnection.java:new org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection(AbfsRestOperationType, URL, String, AuthType, String, List, AbfsFastpathSessionInfo)  At AbfsFastpathConnection.java:[line 94]

Nullcheck of closeResponse at line 271 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathCloseResponse()  At AbfsFastpathConnection.java:271 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathCloseResponse()  At AbfsFastpathConnection.java:[line 271]

Nullcheck of openResponse at line 212 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathOpenResponse()  At AbfsFastpathConnection.java:212 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathOpenResponse()  At AbfsFastpathConnection.java:[line 212]

Nullcheck of readResponse at line 241 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathReadResponse(byte[], int, int)  At AbfsFastpathConnection.java:241 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathReadResponse(byte[], int, int)  At AbfsFastpathConnection.java:[line 241]

Dead store to scheduledFuture in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathSession.updateAbfsFastpathSessionToken(String, OffsetDateTime)  At AbfsFastpathSession.java:org.apache.hadoop.fs.azurebfs.services.AbfsFastpathSession.updateAbfsFastpathSessionToken(String, OffsetDateTime)  At AbfsFastpathSession.java:[line 163]

org.apache.hadoop.fs.azurebfs.services.AbfsHttpConnection.processResponse(byte[], int, int) may fail to close stream  At AbfsHttpConnection.java:to close stream  At AbfsHttpConnection.java:[line 224]

org.apache.hadoop.fs.azurebfs.services.AbfsHttpOperation.getResponseContentBuffer() may expose internal representation by returning AbfsHttpOperation.responseContentBuffer  At AbfsHttpOperation.java:by returning AbfsHttpOperation.responseContentBuffer  At AbfsHttpOperation.java:[line 177]

org.apache.hadoop.fs.azurebfs.services.AbfsRestIODataParameters.getBuffer() may expose internal representation by returning AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:by returning AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:[line 48]

new org.apache.hadoop.fs.azurebfs.services.AbfsRestIODataParameters(byte[], int, int) may expose internal representation by storing an externally mutable object into AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:expose internal representation by storing an externally mutable object into AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:[line 41]

new org.apache.hadoop.fs.azurebfs.services.AbfsRestIODataParameters(byte[], int, int, String) may expose internal representation by storing an externally mutable object into AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:may expose internal representation by storing an externally mutable object into AbfsRestIODataParameters.buffer  At AbfsRestIODataParameters.java:[line 32]

Possible null pointer dereference of httpOperation in org.apache.hadoop.fs.azurebfs.services.AbfsRestOperation.executeHttpOperation(int, TracingContext) on exception path  Dereferenced at AbfsRestOperation.java:httpOperation in org.apache.hadoop.fs.azurebfs.services.AbfsRestOperation.executeHttpOperation(int, TracingContext) on exception path  Dereferenced at AbfsRestOperation.java:[line 350]

Nullcheck of httpOperation at line 385 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsRestOperation.executeHttpOperation(int, TracingContext)  At AbfsRestOperation.java:385 of value previously dereferenced in org.apache.hadoop.fs.azurebfs.services.AbfsRestOperation.executeHttpOperation(int, TracingContext)  At AbfsRestOperation.java:[line 350]

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/4/artifact/out/Dockerfile

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

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

uname
Linux b339fb9d8c31 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 19fdcda3d0b7052911cf983fc6a0a6429e287386

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/4/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/4/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:::: AGGREGATED TEST RESULT ::::
HNS-OAuth
[INFO] Results:
[INFO]
[WARNING] Tests run: 111, Failures: 0, Errors: 0, Skipped: 1
[INFO] Results:
[INFO]
[WARNING] Tests run: 626, Failures: 0, Errors: 0, Skipped: 101
[INFO] Results:
[INFO]
[WARNING] Tests run: 288, Failures: 0, Errors: 0, Skipped: 52
HNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 111, Failures: 0, Errors: 0, Skipped: 7
[INFO] Results:
[INFO]
[WARNING] Tests run: 626, Failures: 0, Errors: 0, Skipped: 137
[INFO] Results:
[INFO]
[WARNING] Tests run: 287, Failures: 0, Errors: 0, Skipped: 68
NonHNS-SharedKey
[INFO] Results:
[INFO]
[WARNING] Tests run: 111, Failures: 0, Errors: 0, Skipped: 7
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   ITestAzureBlobFileSystemCheckAccess.testCheckAccessForAccountWithoutNS:181 Expecting org.apache.hadoop.security.AccessControlException with text "This request is not authorized to perform this operation using this permission.", 403 but got : "void"
[INFO]
[ERROR] Tests run: 626, Failures: 1, Errors: 0, Skipped: 346
[INFO] Results:
[INFO]
[WARNING] Tests run: 287, Failures: 0, Errors: 0, Skipped: 68
AppendBlob-HNS-OAuth
[INFO] Results:
[INFO]
[WARNING] Tests run: 111, Failures: 0, Errors: 0, Skipped: 1
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ITestAzureBlobFileSystemLease.testTwoWritersCreateAppendNoInfiniteLease:178->twoWriters:166 » IO
[INFO]
[ERROR] Tests run: 626, Failures: 0, Errors: 1, Skipped: 101
[INFO] Results:
[INFO]
[WARNING] Tests run: 288, Failures: 0, Errors: 0, Skipped: 100
Test failure observed in NonHNS-SharedKey: ITestAzureBlobFileSystemCheckAccess.testCheckAccessForAccountWithoutNS
is fixed as part of https://issues.apache.org/jira/browse/HADOOP-17767
Test failure observed in AppendBlob-HNS-OAuth: ITestAzureBlobFileSystemLease.testTwoWritersCreateAppendNoInfiniteLease
will be fixed as part of https://issues.apache.org/jira/browse/HADOOP-17590

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m 11s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 41 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m  5s

trunk passed

+1 :green_heart:
compile
0m 51s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 49s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 34s

trunk passed

+1 :green_heart:
mvnsite
0m 46s

trunk passed

+1 :green_heart:
javadoc
0m 34s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 31s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 13s

trunk passed

+1 :green_heart:
shadedclient
20m 21s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
20m 40s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 39s

the patch passed

+1 :green_heart:
compile
0m 36s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 36s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 1 new + 26 unchanged - 1 fixed = 27 total (was 27)

+1 :green_heart:
compile
0m 33s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 33s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 1 new + 20 unchanged - 1 fixed = 21 total (was 21)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 20s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 133 new + 15 unchanged - 4 fixed = 148 total (was 19)

+1 :green_heart:
mvnsite
0m 33s

the patch passed

+1 :green_heart:
xml
0m  1s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 26s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 23s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
spotbugs
1m 22s
/new-spotbugs-hadoop-tools_hadoop-azure.html
hadoop-tools/hadoop-azure generated 4 new + 0 unchanged - 0 fixed = 4 total (was 0)

+1 :green_heart:
shadedclient
19m 29s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m  6s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 33s

The patch does not generate ASF License warnings.

94m  6s

Reason
Tests

SpotBugs
module:hadoop-tools/hadoop-azure

Null passed for non-null parameter of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathCloseResponse()  Method invoked at AbfsFastpathConnection.java:of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathCloseResponse()  Method invoked at AbfsFastpathConnection.java:[line 275]

Null passed for non-null parameter of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathOpenResponse()  Method invoked at AbfsFastpathConnection.java:of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathOpenResponse()  Method invoked at AbfsFastpathConnection.java:[line 217]

Null passed for non-null parameter of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathReadResponse(byte[], int, int)  Method invoked at AbfsFastpathConnection.java:of setStatusFromFastpathResponse(FastpathResponse) in org.apache.hadoop.fs.azurebfs.services.AbfsFastpathConnection.processFastpathReadResponse(byte[], int, int)  Method invoked at AbfsFastpathConnection.java:[line 247]

Boxing/unboxing to parse a primitive org.apache.hadoop.fs.azurebfs.services.AbfsFastpathSession.fetchFastpathSessionToken()  At AbfsFastpathSession.java:org.apache.hadoop.fs.azurebfs.services.AbfsFastpathSession.fetchFastpathSessionToken()  At AbfsFastpathSession.java:[line 206]

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/5/artifact/out/Dockerfile

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

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

uname
Linux 54d016294e9e 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 43ce27b5252f5c31763f37d03f3708b34b5c0c5b

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/5/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/5/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 58s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  2s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 41 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 19s

trunk passed

+1 :green_heart:
compile
0m 38s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 31s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 24s

trunk passed

+1 :green_heart:
mvnsite
0m 37s

trunk passed

+1 :green_heart:
javadoc
0m 30s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 26s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
0m 59s

trunk passed

+1 :green_heart:
shadedclient
17m  7s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
17m 28s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 34s

the patch passed

+1 :green_heart:
compile
0m 33s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 33s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 1 new + 26 unchanged - 1 fixed = 27 total (was 27)

+1 :green_heart:
compile
0m 29s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 29s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 1 new + 20 unchanged - 1 fixed = 21 total (was 21)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 18s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 16 new + 14 unchanged - 5 fixed = 30 total (was 19)

+1 :green_heart:
mvnsite
0m 33s

the patch passed

+1 :green_heart:
xml
0m  3s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 24s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 22s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m 15s

the patch passed

+1 :green_heart:
shadedclient
18m 36s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1m 59s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 30s

The patch does not generate ASF License warnings.

82m  7s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/6/artifact/out/Dockerfile

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

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

uname
Linux 58aa7567264c 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 20181aa5fbb0dc4a186a1f12616293763501c9da

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/6/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/6/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 54s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 37 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
33m 31s

trunk passed

+1 :green_heart:
compile
0m 36s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 31s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 24s

trunk passed

+1 :green_heart:
mvnsite
0m 37s

trunk passed

+1 :green_heart:
javadoc
0m 28s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 26s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  0s

trunk passed

+1 :green_heart:
shadedclient
16m 35s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
16m 54s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 33s

the patch passed

+1 :green_heart:
compile
0m 31s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 31s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 1 new + 26 unchanged - 1 fixed = 27 total (was 27)

+1 :green_heart:
compile
0m 26s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 26s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 1 new + 20 unchanged - 1 fixed = 21 total (was 21)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

-0 :warning:
checkstyle
0m 17s
/results-checkstyle-hadoop-tools_hadoop-azure.txt
hadoop-tools/hadoop-azure: The patch generated 2 new + 14 unchanged - 5 fixed = 16 total (was 19)

+1 :green_heart:
mvnsite
0m 30s

the patch passed

+1 :green_heart:
xml
0m  3s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 22s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 20s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  2s

the patch passed

+1 :green_heart:
shadedclient
16m 43s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1m 58s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 29s

The patch does not generate ASF License warnings.

79m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/7/artifact/out/Dockerfile

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

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

uname
Linux 317899f260ea 4.15.0-147-generic #151-Ubuntu SMP Fri Jun 18 19:21:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 4889a9d0ca32bf4950f78f16c788b055a9f198e1

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/7/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/7/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  2s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 37 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m  3s

trunk passed

+1 :green_heart:
compile
0m 40s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 36s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 29s

trunk passed

+1 :green_heart:
mvnsite
0m 41s

trunk passed

+1 :green_heart:
javadoc
0m 34s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 30s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  2s

trunk passed

+1 :green_heart:
shadedclient
14m  8s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
14m 27s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 35s

the patch passed

+1 :green_heart:
compile
0m 31s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 31s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 2 new + 25 unchanged - 1 fixed = 27 total (was 26)

+1 :green_heart:
compile
0m 27s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 27s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 2 new + 19 unchanged - 1 fixed = 21 total (was 20)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 18s

hadoop-tools/hadoop-azure: The patch generated 0 new + 12 unchanged - 7 fixed = 12 total (was 19)

+1 :green_heart:
mvnsite
0m 31s

the patch passed

+1 :green_heart:
xml
0m  3s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 25s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 22s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  1s

the patch passed

+1 :green_heart:
shadedclient
14m  3s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
1m 55s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 33s

The patch does not generate ASF License warnings.

73m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/8/artifact/out/Dockerfile

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

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

uname
Linux 74655aa0a0ea 4.15.0-151-generic #157-Ubuntu SMP Fri Jul 9 23:07:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ab5b33ceaec0587eac37b8406a25ef04a47b1681

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/8/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/8/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 43s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  2s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 37 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
31m 34s

trunk passed

+1 :green_heart:
compile
0m 41s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
compile
0m 34s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
checkstyle
0m 28s

trunk passed

+1 :green_heart:
mvnsite
0m 39s

trunk passed

+1 :green_heart:
javadoc
0m 32s

trunk passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 30s

trunk passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  2s

trunk passed

+1 :green_heart:
shadedclient
14m 12s

branch has no errors when building and testing our client artifacts.

-0 :warning:
patch
14m 31s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 34s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

-1 :x:
javac
0m 32s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04.txt
hadoop-tools_hadoop-azure-jdkUbuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 generated 1 new + 24 unchanged - 2 fixed = 25 total (was 26)

+1 :green_heart:
compile
0m 27s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

-1 :x:
javac
0m 27s
/results-compile-javac-hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10.txt
hadoop-tools_hadoop-azure-jdkPrivateBuild-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10 generated 1 new + 18 unchanged - 2 fixed = 19 total (was 20)

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 20s

hadoop-tools/hadoop-azure: The patch generated 0 new + 11 unchanged - 10 fixed = 11 total (was 21)

+1 :green_heart:
mvnsite
0m 31s

the patch passed

+1 :green_heart:
xml
0m  4s

The patch has no ill-formed XML file.

+1 :green_heart:
javadoc
0m 24s

the patch passed with JDK Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04

+1 :green_heart:
javadoc
0m 22s

the patch passed with JDK Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

+1 :green_heart:
spotbugs
1m  8s

the patch passed

+1 :green_heart:
shadedclient
14m  9s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m  5s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 34s

The patch does not generate ASF License warnings.

73m 24s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/9/artifact/out/Dockerfile

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

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

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 3bd7ce82e38ef0aa13994aeac65c579bad64b46d

Default Java
Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.11+9-Ubuntu-0ubuntu2.20.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_292-8u292-b10-0ubuntu1~20.04-b10

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/9/testReport/

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

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-3309/9/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.


npm start can't start

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/node/bin/node', '/usr/sbin/npm', 'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info prestart<EMAIL_ADDRESS>6 verbose unsafe-perm in lifecycle true
7 info start<EMAIL_ADDRESS>8 verbose unsafe-perm in lifecycle true
9 info<EMAIL_ADDRESS>Failed to exec start script
10 verbose stack Error<EMAIL_ADDRESS>start: node app.js
10 verbose stack Exit status 1
10 verbose stack     at EventEmitter. (/usr/local/node/lib/node_modules/npm/lib/utils/lifecycle.js:213:16)
10 verbose stack     at EventEmitter.emit (events.js:110:17)
10 verbose stack     at ChildProcess. (/usr/local/node/lib/node_modules/npm/lib/utils/spawn.js:14:12)
10 verbose stack     at ChildProcess.emit (events.js:110:17)
10 verbose stack     at maybeClose (child_process.js:1008:16)
10 verbose stack     at Process.ChildProcess._handle.onexit (child_process.js:1080:5)
11 verbose pkgid<EMAIL_ADDRESS>12 verbose cwd /root/chat/lets-chat
13 error Linux 2.6.32-4<IP_ADDRESS>.1.el6.x86_64
14 error argv "/usr/local/node/bin/node" "/usr/sbin/npm" "start"
15 error node v0.12.0
16 error npm  v2.5.1
17 error code ELIFECYCLE
18 error<EMAIL_ADDRESS>start: node app.js
18 error Exit status 1
19 error Failed at the<EMAIL_ADDRESS>start script 'node app.js'.
19 error This is most likely a problem with the lets-chat package,
19 error not with npm itself.
19 error Tell the author that this fails on your system:
19 error     node app.js
19 error You can get their info via:
19 error     npm owner ls lets-chat
19 error There is likely additional logging output above.
20 verbose exit [ 1, true ]

try move to nodejs v0.10.9

0 info it worked if it ends with ok
1 verbose cli [ 'node', '/usr/local/bin/npm', 'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info prestart<EMAIL_ADDRESS>6 verbose unsafe-perm in lifecycle true
7 info start<EMAIL_ADDRESS>8 verbose unsafe-perm in lifecycle true
9 info<EMAIL_ADDRESS>Failed to exec start script
10 verbose stack Error<EMAIL_ADDRESS>start: node app.js
10 verbose stack Exit status 8
10 verbose stack     at EventEmitter. (/usr/local/lib/node_modules/npm/lib/utils/lifecycle.js:213:16)
10 verbose stack     at EventEmitter.emit (events.js:98:17)
10 verbose stack     at ChildProcess. (/usr/local/lib/node_modules/npm/lib/utils/spawn.js:14:12)
10 verbose stack     at ChildProcess.EventEmitter.emit (events.js:98:17)
10 verbose stack     at maybeClose (child_process.js:735:16)
10 verbose stack     at Process.ChildProcess._handle.onexit (child_process.js:802:5)
11 verbose pkgid<EMAIL_ADDRESS>12 verbose cwd /root/chat/lets-chat
13 error Linux 2.6.32-4<IP_ADDRESS>.1.el6.x86_64
14 error argv "node" "/usr/local/bin/npm" "start"
15 error node v0.10.9
16 error npm  v2.7.0
17 error code ELIFECYCLE
18 error<EMAIL_ADDRESS>start: node app.js
18 error Exit status 8
19 error Failed at the<EMAIL_ADDRESS>start script 'node app.js'.
19 error This is most likely a problem with the lets-chat package,
19 error not with npm itself.
19 error Tell the author that this fails on your system:
19 error     node app.js
19 error You can get their info via:
19 error     npm owner ls lets-chat
19 error There is likely additional logging output above.
20 verbose exit [ 1, true ]

try move to x86

Hello, could you please use https://groups.google.com/forum/m/#!forum/lets-chat-app
For your deployment question? Also, please post your operating system, etc


How to perform a nearsphere find action?

Suppose I want  perform a nearsphere like the following  :
      db.pois.find({"loc":{"$nearSphere":{"$geometry":{"type":"Point","coordinates":[118.606743,30.053336]},"$maxDistance":5000, "$minDistance":0}}})

How can I do  that by reactivemongo in Play framework?

Hi, please first have a look at the documentation (see how to find documents). If you have a question not covered by this doc, then you can use the user MailingList rather than this issue tracker. Best regards.


XML Comparison - ignore URN (URI)

Hi,
When comparing two xml files, how can we ignore the URI?

Thanks in advance!

Hi, I'm not sure I understand the question, can you tell me more and show me a screenshot of what you don't like? Thanks.

I added some filtering functionality which could be modified to exclude certain nodes in PR #90 - that hasn't made its way across Chris's desk yet


update POI libraies to 1.15

Currently the poi libraries are 2 years old.

I will try to get this updated this weekend and cut a new release of the gem. Sorry this is so far behind and not very well maintained.

Updated to 3.15.


Repeats event

Describe the bug
A clear and concise description of what the bug is.
Not a Bug
To Reproduce
I need to register a multiple events every days of the week
Please provide one or both of the following:
Code (If you have a branch somewhere that shows your issue) or link to codesandbox example. Here's a base template for this library:
OR
Steps to reproduce the behavior:

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

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Library Version
Please provide version of library in which this bug is occurring.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Looks like nothing is happening :)


RPC Controller __construct gives "Unable to fetch RPC services"

Adding a __construct to a RPC controller causes the ui to give the "Unable to fetch RPC services" error and the RPC services names aren't in the list anymore. I can use them through postman just fine though.
Using version: 1.5.9 installed with composer require of "zfcampus/zf-apigility".

Maybe a little late, but I had the same error today.
My issue was this :
I had copied my controller code because an other service was pretty much the same.
I missed the namespace (first line of php code in de controller file) and it was still set to the other service name.
This produced this error, after updating the namespace everything was working fina again.


Break up subjects default add_column migration

Let's try and avoid locking the large table so this will remove the addtional non-null constraint with the default value. On Staging - I'm going to undo the prev migration so this can run correctly this time.
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

Looks like the Activatable concern doesn't like it if there's no default value?

LGTM


BUG: Can't update with notification service

Describe the bug
Error on update all
TIME:<PHONE_NUMBER>489819301
PLAYBOOK: /opt/stereum/ansible/controls/genericPlaybook.yaml
TASK: Get latest version for this service
ACTION: set_fact
CATEGORY: FAILED
DATA: {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'NotificationService'. 'dict object' has no attribute 'NotificationService'\n\nThe error appears to be in '/opt/stereum/ansible/controls/roles/update-services/tasks/update-service.yml': line 18, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Get latest version for this service\n  ^ here\n", "_ansible_no_log": false}

To Reproduce
Steps to reproduce the behavior:

Setup a node with notification service
Update All
See error

Screenshots

Desktop (please complete the following information):

OS: MacOS
Launcher version 2.0.0-rc.15

Node (please complete the following information):

OS: Ubuntu 22.04
Affected service: Notification service

added it to updates.json


Photon particle designation needed

There needs to be a way to label a particle to be a photon.

There is one, in the subatomic_particles dictionary. Does it need additional structures like frequency and polarization?

Stuff like frequency are external to the APC package.


add new fields to Suggestion

add administrative_area_short and administrative_area_long to suggestion in international autocomplete sdk
clickup: https://app.clickup.com/t/86b2xtrw1

I just came across this issue. Getting this merged will be a huge help!

I just came across this issue myself. Getting this merged will be a huge help!

New fields are merged in!


Failed fetching org-users for role ORG MANAGER, status code 500, error code 10001

Hi Expert,
cf login success with --skip-ssl-validation. Create user, space, assigning user role works fine.
But when run "cf org-users", get below error.
Failed fetching org-users for role ORG MANAGER.
Server error, status code: 500, error code: 10001, message: An unknown error occurred.
Check controller logs, find that
{"timestamp":1438705617.9227388,"message":"Request failed: 500: {"code"=>10001, "description"=>"Invalid SSL Cert for https://uaa.<IP_ADDRESS>.xip.io/oauth/token. Use '--skip-ssl-validation' to continue with an insecure target", "error_code"=>"CF-SSLException", "backtrace"=>["/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/cache/cf-uaa-lib-b1e11235dc6c/lib/uaa/http.rb:169:
I use self signed certificate.
My questions is:
1, Is there away to skip cert validation when run "cf org-users" ? Or some other solution?
2, in cf-deployment.yml, there are 3 components need to input cert(or key pair) - haproxy, router, uaa token. Should I use same key pair for the 3 components? or I need to generate key pair(cert ) for each components?
any experience and suggestions?
thanks,
David

You should be able to set skip_cert_verify to true in your deployment manifest to configure this.
properties:
  ssl:
    skip_cert_verify: true

@jpalermo & @danlavine
OSS Release Integration Team

Thanks you DanLavine, it works.
BTW

skip_cert_verify: true is not secure. Is there some other way to solve this issue?
If  a company depoy CF with  company CA(root  CA cert is not trusted), how can we make it works with skip_cert_verify: fasle? Import the company root CA cert into stemcell?

I don't think there are guidelines on how to do it, but yes the root cert would probably have to be built into a custom stemcell.
I don't recall this ever coming up before. @cppforlife, do you know if this has been done?
I would guess that most companies would have a cert that was signed by a trusted root CA.
OSS Release Integration Team

Thank you jpalermo.
The root cert can be import into bosh director by bosh manifest, then bosh director will import root cert to CF VMs.
I have a done a test, it works fine.

Great to hear.
Here are the docs for anybody else who finds this page:
http://bosh.io/docs/trusted-certs.html


chore(ci): fix BrowserStack timeouts

Assuming that the issue is concurrent jobs attempting to interact with BrowserStack using the same build ID, this solution attempts to solve it by only interacting with BrowserStack in one of the jobs.
Updated build definition:

runs complete build on the latest Node
runs simplified build (without commit validation, lint, test:client and test:integration) on earlier versions on Node

It is not very valuable to run omitted test suits multiple times as they supposed to catch issues, which are usually Node-independent: client code fails in some browsers and API breaking changes, which will affect popular Karma plugins.
Fixes #3468

This branch uses real BS even for the builds from PR and conflicts with the build running from master at the same time... I'll re-open it from my own repository to mitigate it.


No such file or directory

I train the model after I refer to GET_STARTED.md for preparation. However, the following problems have arisen：
FileNotFoundError: [Errno 2] No such file or directory: 'data/bdd/images/10k/train/fee92217-63b3f87f.jpg'.
I checked the json file and the dataset. I found that certain image names appear in the json file, but could not find the jpg file in the corresponding folder. Please help me!

So far I only found four  image missing(fee92217-63b3f87f.jpg,ff1e4d6d-f4d85cfd.jpg,ff3d3536-04986e25.jpg,ff3da814-c3463a43.jpg). It is worth noting that the number of files in the “bdd100k/labels/ins_seg/bitmasks/train” folder is the same as the number of files in the “bdd100k/images/10k/train” folder. I guess there are other similar situations.

Hi, is just this single image missing or missing a lot of image files?

So far I only found four image missing(fee92217-63b3f87f.jpg,ff1e4d6d-f4d85cfd.jpg,ff3d3536-04986e25.jpg,ff3da814-c3463a43.jpg). It is worth noting that the number of files in the “bdd100k/labels/ins_seg/bitmasks/train” folder is the same as the number of files in the “bdd100k/images/10k/train” folder. I guess there are other similar situations.

are you donwloading from the lastest dataset from BDD100k?

I downloading all the dataset and label from https://bdd-data.berkeley.edu/portal.html#download.

I guess you also need to download the lastest coco json file instead of using the converted one provided by the repo. Or you can remove these 4 images first.

I think you also need to download the lastest coco json file instead of using the converted one provided by the repo. Or you can remove these 4 images first.

Thank you for your patience, I have solved the problem by removing the label information associated with the four images in the json file.


Remove redundant require 'set'

Follow https://github.com/rubocop-hq/rubocop/commit/8798bc8.
RuboCop AST 0.1.0 requires Set.
https://github.com/rubocop-hq/rubocop-ast/commit/8e595c3.
RuboCop requires RuboCop AST 0.1.0 or higher. Therefore this PR removes redundant require 'set'.

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[ ] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
[x] Run bundle exec rake default. It executes all tests and RuboCop for itself, and generates the documentation.

I think files that explicitly calls e.g. Set.new should still keep the require.

I'm curious why. I hope I didn't start a big argument (especially since there's really not much at stake). My opinion if that sets should be builtin and most gems should currently require it, once, where the files are loaded (like we do in rubocop & rubocop-ast). We don't require other external dependencies where we use them either (e.g. parser)...

First, I agree that Set should be built-in.

gems should currently require it, once, where the files are loaded (like we do in rubocop & rubocop-ast).

I read the PR description as if RuboCop should not require Set, and just depend on rubocop-ast requiring it. That feels wrong.
Re. requiring external dependencies in each file where they’re used: It makes testing easier/faster and it makes code easier to reuse in smaller chunks (think e.g. requiring activesupport/core_ext/string ) if you aren’t depending on always loading up the entire library and all it’s dependencies.

I read the PR description as if RuboCop should not require Set, and just depend on rubocop-ast requiring it. That feels wrong.

That's my fault, I mentioned rubocop-ast but in this case rubocop also requires it explicitly. Note that parser is only required once in rubocop-ast.

requiring external dependencies in each file where they’re used: It makes testing easier/faster  and it makes code easier to reuse in smaller chunks

You are right for reuse in smaller chunks, but we don't (yet?) support it.
I don't feel strongly about it.

First, I agree that Set should be built-in.

If you have the time, please comment positively on the Set issues (and negatively only here 😆). There was basically zero feedback by anybody 🤷♂

Thank you for the argument. I've updated this PR so that RuboCop explicitly requires set only once in the following lib/rubocop.rb.
https://github.com/rubocop-hq/rubocop/blob/v0.88.0/lib/rubocop.rb#L6
It refocuses on the obviously redundant code in the rubocop repository.


Spaces are getting replaced in workflow inputs

Describe the Bug with repro steps
The latest version of standard logic app changes the space in message input body with some other characters.
Here is sample input message - EU-231K-00LI-RSVR-01.PV; 2023/9/22 2:0:4; 0
There are spaces in the date time format.
But if this input is passed to an HTTP action it removes the space from the message body.

This is the expected behavior.

If we do control + f, and search for space, it should show the spaces in message body as well.
What type of Logic App Is this happening in?
Standard (Portal)
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
All browsers
Additional context
No response
AB#25386698

Hi @harry6561 thanks for reporting this issue. I tried reproducing your issue, but didn't seem to have the same issue - when looking at the input for my HTTP body action on a flow run, it seemed to still be able to see the white space. What I think may be happening is that the sample input message you are using: "EU-231K-00LI-RSVR-01.PV; 2023/9/22 2:0:4; 0" might not be using a space, but rather a different character that may look like a space. If you try copying the space from your input (where the space is not working) and paste it to a unicode identifier site ex. https://www.babelstone.co.uk/Unicode/whatisit.html, you'll be able to see what character is being for your input.

@Eric-B-Wu : Thanks for the update. My input message has no-break space.

But it was detected as space in logic app before. It still works fine in runtime version - <IP_ADDRESS>38
It seems to have changed from runtime - <IP_ADDRESS>86. Currently it is not recognized as a space. Please let me know if you need more details.

In which case, let me transfer you to the backend, as they handle what happens at runtime, and they can follow up if anything changed there or if this was an intended


Crash on MicrophoneAudioSource.read()

I have an issue with the audio access with the example code from the README, probably due to my audio setup:
>>> mic.read()
torch.Size([4, 512])
python: src/hostapi/alsa/pa_linux_alsa.c:3641: PaAlsaStreamComponent_BeginPolling: Assertion `ret == self->nfds' failed.
Aborted (core dumped)

This is strange because I'm running this in a Docker container and I also use the sounddevice library without problems in another project in the same container.
Originally posted by @KannebTo in https://github.com/juanmc2005/StreamingSpeakerDiarization/issues/8#issuecomment-949453753

This should be solved in #19. Feel free to reopen if needed.


Next graphics - scrollRect doesn't work (OpenFLNextShapeTest #3)

Test case: https://github.com/jcward/OpenFLNextShapeTest
scrollRect doesn't work
Potentially related to #529

Tested with latest source and html5 target, this problem seems fixed:

Did it also work on cpp/neko?

Oh, no, the issues all still exist on cpp/neko...  I'll reopen for that reason, but I presume @jgranick asked the try html5 becasue it has the latest code?

Ping @mrcdk

When we test in HTML5, it helps confirm if this works in "next" at all.
The canvas renderer (which is default in HTML5) is more mature than the newer OpenGL renderer, though it is simpler to write a canvas renderer, probably, anyway :wink:
It helps us drill down on what's really going on. For example, the bounds check was wrong in HTML5 as well -- we knew it wasn't (likely) a renderer-related problem. scrollRect was tricky to get right, but I think HTML5 has it fully done and working :smile:

Yeah makes sense! But just to be clear: the closing state of this issue is works in cpp/neko AND html5 tho, right?

FYI, here again, there should be a matrix that controls the positioning and size of the gradient.

Hmmm, good point. Let's test what happens if we put the object at 0,0 and don't rotate it. It'd be handy if all it was, was a matrix not being passed in. Doubt we're that lucky tho :P

Okay, on HTML5 position & rotation of the shape doesn't seem to affect gradient wrong-ness any more than it already is, so that easy check is taken care of.

Right, not the Shape's position matrix, but when you define a gradient, there's a different matrix that controls the coloring size/positioning via createGradientBox. I believe this is where this bug stems from. e.g. from my testcase:
// Gradient helper
private static var GRADIENT_M:flash.geom.Matrix = new flash.geom.Matrix();
public static function begin_gradient(g:openfl.display.Graphics,
                                      w:Float,
                                      h:Float,
                                      c1:UInt=0x444444,
                                      c2:UInt=0x535353,
                                      angle:Float=-1.5757963):Void
{
  GRADIENT_M.identity();
  GRADIENT_M.createGradientBox(w, h, angle);
  g.beginGradientFill(openfl.display.GradientType.LINEAR,
                      [c1,c2],
                      [1,1],
                      [0,255],
                      GRADIENT_M);
}

ah interesting, soon as I have a chance I'll look into that.

Oops - this is the wrong bug, the gradient issue is #644 - this bug is the scrollRect issue.  I've moved my above comment there.

Recreating a new Rectangle over the old scrollRect is one way to workaround this until it is fixed.
Someone suggested fixing it (via #529) by removing the if statement to call __setTransformDirty() every time it is changed. Unless this has been resolved in a patch that has not yet been released some other way.

I tried and I actually have it working on native but not html5.

#901 related at all?

should be fixed, thanks :smile:


Feat/puzzle response

Motivation
Client or Prover should only process the latest PuzzleResponse.

Sync already ensures that the client/prover will only request a PuzzleRequest with a specific set of peers if it deems them to be further on the canonical chain. Additionally, we enforce that a PuzzleResponse message is only processed from a peer if the node sent a PuzzleRequest to that peer. So we only process responses which we asked for.
In the case that the network is partitioned or forked, this proposed change introduces risk that the provers will not target the rebased chain (i.e. the new canonical ledger).

Sync already ensures that the client/prover will only request a PuzzleRequest with a specific set of peers if it deems them to be further on the canonical chain. Additionally, we enforce that a PuzzleResponse message is only processed from a peer if the node sent a PuzzleRequest to that peer. So we only process responses which we asked for.
In the case that the network is partitioned or forked, this proposed change introduces risk that the provers will not target the rebased ledger (i.e. the new canonical chain).

It seems reasonable when the network is stable. However, I push the Prover current_height metrics to exporter, it seems like sometimes the current_height decline sharply。

Sync already ensures that the client/prover will only request a PuzzleRequest with a specific set of peers if it deems them to be further on the canonical chain. Additionally, we enforce that a PuzzleResponse message is only processed from a peer if the node sent a PuzzleRequest to that peer. So we only process responses which we asked for.
In the case that the network is partitioned or forked, this proposed change introduces risk that the provers will not target the rebased ledger (i.e. the new canonical chain).

We will modify the MessageVersion in order to force provers to target the rebased target？

Prover/Client will not process block_request and block_response now, and never update itself's canon chain, If I'm not mistaken.
Please check this logic, thanks.

I see your point here, let me think about it. While the drop in height isn't great, it is frankly the correct behavior.
We should be optimizing for higher quality peers, as opposed to artificially preserving (stale) block locators.

All right. Not as you say "drop in height isn't great", it's even worse now, more frequent, greater height.
Scoring mechanism is needed.
There's no reward for Provers to broadcast proofs to theirs connected peers, but just drop the proofs is benefit.