Errors with CWL and joint VC

Hello,
I'm noticing some errors when running joint calling with multiple variant callers and ensemble mode. The input files are the same as here: https://github.com/bcbio/bcbio-nextgen/issues/2688#issue-412394726
The difference is in the variant callers setup and with using CWL with a local bcbio_nextgen instead of directly running things in bcbio_nextgen. I'm really interested in the ensemble multi-VC scenario with joint genotyping.
CWL ran fine with one VC (so far tested with HaplotypeCaller and Strelka2). When using both callers and enabling ensemble mode (numpass: 2), I get the following error:
Traceback (most recent call last):
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/tools/bin/bcbio_nextgen.py", line 223, in <module>
    runfn.process(kwargs["args"])
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/distributed/runfn.py", line 57, in process
    out = fn(*fnargs)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/utils.py", line 55, in wrapper
    return f(*args, **kwargs)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/distributed/multitasks.py", line 348, in batch_for_ensemble
    return ensemble.batch(*args)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/variation/ensemble.py", line 32, in batch
    samples = [utils.to_single_data(x) for x in samples]
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/utils.py", line 157, in to_single_data
    assert isinstance(input, dict), input
AssertionError: [{'dirs': {'work': '/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/execution'}, 'rgnames': {'sample': u'HG00096'}, u'vrn_file': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-838467116/HG00096.vcf.gz', u'description': u'HG00096', u'reference': {u'snpeff': {u'GRCh38_86': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/852345369/snpeff--GRCh38.86-wf.tar.gz'}, u'genome_context': [u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1262387051/LCR.bed.gz', u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1262387051/polyx.bed.gz', u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1262387051/rmsk.gtf.gz'], u'fasta': {u'base': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/34938063/hg38.fa'}, u'rtg': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/852345369/rtg--hg38.sdf-wf.tar.gz'}, u'batch_samples': [u'HG00096'], 'output_cwl_keys': {'ensemble_prep_rec': ['batch_id', 'variants__calls', 'variants__variantcallers', 'resources', 'description', 'batch_samples', 'validate__summary', 'validate__tp', 'validate__fp', 'validate__fn', 'vrn_file', 'metadata__phenotype', 'genome_resources__variation__1000g', 'genome_resources__variation__train_hapmap', 'config__algorithm__min_allele_fraction', 'config__algorithm__validate_regions', 'config__algorithm__tools_on', 'config__algorithm__variant_regions', 'config__algorithm__variantcaller', 'reference__snpeff__GRCh38_86', 'genome_resources__variation__clinvar', 'reference__genome_context', 'metadata__batch', 'genome_build', 'genome_resources__aliases__human', 'genome_resources__variation__encode_blacklist', 'genome_resources__variation__dbsnp', 'config__algorithm__ensemble', 'config__algorithm__effects', 'genome_resources__aliases__ensembl', 'config__algorithm__exclude_regions', 'reference__fasta__base', 'genome_resources__variation__exac', 'genome_resources__variation__gnomad_exome', 'config__algorithm__coverage_interval', 'genome_resources__variation__polyx', 'genome_resources__variation__cosmic', 'config__algorithm__vcfanno', 'genome_resources__aliases__snpeff', 'reference__rtg', 'genome_resources__variation__lcr', 'genome_resources__variation__esp', 'config__algorithm__validate', 'config__algorithm__tools_off', 'analysis', 'genome_resources__variation__train_indels', 'config__algorithm__variant_regions_merged', 'regions__sample_callable', 'config__algorithm__callable_regions', 'vrn_file_joint']}, u'vrn_file_joint': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1051353122/testingVC-annotated-nomissingalt-filterSNP-filterINDEL.vcf.gz', u'analysis': u'variant2', u'regions': {u'sample_callable': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1174113760/HG00096-sort-callable_sample.bed'}, u'genome_build': u'hg38', 'cwl_keys': [u'metadata__phenotype', u'config__algorithm__validate', u'reference__fasta__base', u'reference__rtg', u'genome_resources__variation__lcr', u'vrn_file_joint', u'validate__summary', u'genome_resources__variation__exac', u'reference__snpeff__GRCh38_86', u'genome_resources__variation__1000g', u'regions__sample_callable', u'config__algorithm__coverage_interval', u'genome_resources__variation__train_hapmap', u'validate__fp', u'genome_resources__variation__clinvar', u'genome_resources__variation__esp', u'reference__genome_context', u'metadata__batch', u'batch_samples', u'config__algorithm__min_allele_fraction', u'validate__tp', u'validate__fn', u'resources', u'config__algorithm__callable_regions', u'description', u'config__algorithm__validate_regions', u'config__algorithm__variantcaller', u'genome_build', u'config__algorithm__exclude_regions', u'genome_resources__aliases__human', u'genome_resources__variation__encode_blacklist', u'config__algorithm__tools_off', u'genome_resources__variation__dbsnp', u'vrn_file', u'genome_resources__variation__polyx', u'genome_resources__variation__cosmic', u'config__algorithm__ensemble', u'config__algorithm__vcfanno', u'analysis', u'config__algorithm__variant_regions_merged', u'config__algorithm__tools_on', u'config__algorithm__effects', u'config__algorithm__variant_regions', u'genome_resources__aliases__ensembl', u'genome_resources__variation__gnomad_exome', u'genome_resources__variation__train_indels', u'genome_resources__aliases__snpeff'], u'genome_resources': {u'variation': {u'clinvar': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/747486603/clinvar.vcf.gz', u'polyx': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1262387051/polyx.bed.gz', u'lcr': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1262387051/LCR.bed.gz', u'encode_blacklist': None, u'esp': None, u'exac': None, u'cosmic': None, u'gnomad_exome': None, u'1000g': None, u'train_hapmap': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/747486603/hapmap_3.3.vcf.gz', u'dbsnp': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/747486603/dbsnp-151.vcf.gz', u'train_indels': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/747486603/Mills_and_1000G_gold_standard.indels.vcf.gz'}, u'aliases': {u'snpeff': u'GRCh38.86', u'human': True, u'ensembl': u'homo_sapiens_merged_vep_95_GRCh38'}}, u'validate': {u'fp': None, u'fn': None, u'tp': None, u'summary': None}, u'config': {'resources': {u'default': {'cores': 1, 'jvm_opts': ['-Xms1000m', '-Xmx3072m'], 'memory': '3072M'}}, u'algorithm': {u'exclude_regions': [], u'min_allele_fraction': 10, 'num_cores': 1, u'vcfanno': [], u'variantcaller': u'gatk-haplotype', u'validate_regions': None, u'tools_off': [u'gemini', u'contamination', u'peddy'], u'variant_regions_merged': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-2011195376/cleaned-variant_regions-merged.bed', u'ensemble': u'{"numpass": 2}', u'variant_regions': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-2011195376/cleaned-variant_regions.bed', u'coverage_interval': u'amplicon', u'tools_on': [u'gvcf'], u'validate': None, u'callable_regions': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1986227072/testingVC-analysis_blocks.bed', u'effects': False}}, u'resources': {u'default': {'cores': 1, 'jvm_opts': ['-Xms1000m', '-Xmx3072m'], 'memory': '3072M'}}, u'metadata': {u'phenotype': u'', u'batch': u'testingVC'}}, {'dirs': {'work': '/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/execution'}, 'rgnames': {'sample': u'HG00097'}, u'vrn_file': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/1534265734/HG00097.vcf.gz', u'description': u'HG00097', u'reference': {u'snpeff': {u'GRCh38_86': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/1745172351/snpeff--GRCh38.86-wf.tar.gz'}, u'genome_context': [u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-475581783/LCR.bed.gz', u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-475581783/polyx.bed.gz', u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-475581783/rmsk.gtf.gz'], u'fasta': {u'base': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1455071080/hg38.fa'}, u'rtg': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/1745172351/rtg--hg38.sdf-wf.tar.gz'}, u'batch_samples': [u'HG00097'], 'output_cwl_keys': {'ensemble_prep_rec': ['batch_id', 'variants__calls', 'variants__variantcallers', 'resources', 'description', 'batch_samples', 'validate__summary', 'validate__tp', 'validate__fp', 'validate__fn', 'vrn_file', 'metadata__phenotype', 'genome_resources__variation__1000g', 'genome_resources__variation__train_hapmap', 'config__algorithm__min_allele_fraction', 'config__algorithm__validate_regions', 'config__algorithm__tools_on', 'config__algorithm__variant_regions', 'config__algorithm__variantcaller', 'reference__snpeff__GRCh38_86', 'genome_resources__variation__clinvar', 'reference__genome_context', 'metadata__batch', 'genome_build', 'genome_resources__aliases__human', 'genome_resources__variation__encode_blacklist', 'genome_resources__variation__dbsnp', 'config__algorithm__ensemble', 'config__algorithm__effects', 'genome_resources__aliases__ensembl', 'config__algorithm__exclude_regions', 'reference__fasta__base', 'genome_resources__variation__exac', 'genome_resources__variation__gnomad_exome', 'config__algorithm__coverage_interval', 'genome_resources__variation__polyx', 'genome_resources__variation__cosmic', 'config__algorithm__vcfanno', 'genome_resources__aliases__snpeff', 'reference__rtg', 'genome_resources__variation__lcr', 'genome_resources__variation__esp', 'config__algorithm__validate', 'config__algorithm__tools_off', 'analysis', 'genome_resources__variation__train_indels', 'config__algorithm__variant_regions_merged', 'regions__sample_callable', 'config__algorithm__callable_regions', 'vrn_file_joint']}, u'vrn_file_joint': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1051353122/testingVC-annotated-nomissingalt-filterSNP-filterINDEL.vcf.gz', u'analysis': u'variant2', u'regions': {u'sample_callable': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-851074267/HG00097-sort-callable_sample.bed'}, u'genome_build': u'hg38', 'cwl_keys': [u'metadata__phenotype', u'config__algorithm__validate', u'reference__fasta__base', u'reference__rtg', u'genome_resources__variation__lcr', u'vrn_file_joint', u'validate__summary', u'genome_resources__variation__exac', u'reference__snpeff__GRCh38_86', u'genome_resources__variation__1000g', u'regions__sample_callable', u'config__algorithm__coverage_interval', u'genome_resources__variation__train_hapmap', u'validate__fp', u'genome_resources__variation__clinvar', u'genome_resources__variation__esp', u'reference__genome_context', u'metadata__batch', u'batch_samples', u'config__algorithm__min_allele_fraction', u'validate__tp', u'validate__fn', u'resources', u'config__algorithm__callable_regions', u'description', u'config__algorithm__validate_regions', u'config__algorithm__variantcaller', u'genome_build', u'config__algorithm__exclude_regions', u'genome_resources__aliases__human', u'genome_resources__variation__encode_blacklist', u'config__algorithm__tools_off', u'genome_resources__variation__dbsnp', u'vrn_file', u'genome_resources__variation__polyx', u'genome_resources__variation__cosmic', u'config__algorithm__ensemble', u'config__algorithm__vcfanno', u'analysis', u'config__algorithm__variant_regions_merged', u'config__algorithm__tools_on', u'config__algorithm__effects', u'config__algorithm__variant_regions', u'genome_resources__aliases__ensembl', u'genome_resources__variation__gnomad_exome', u'genome_resources__variation__train_indels', u'genome_resources__aliases__snpeff'], u'genome_resources': {u'variation': {u'clinvar': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1273576180/clinvar.vcf.gz', u'polyx': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-475581783/polyx.bed.gz', u'lcr': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-475581783/LCR.bed.gz', u'encode_blacklist': None, u'esp': None, u'exac': None, u'cosmic': None, u'gnomad_exome': None, u'1000g': None, u'train_hapmap': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1273576180/hapmap_3.3.vcf.gz', u'dbsnp': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1273576180/dbsnp-151.vcf.gz', u'train_indels': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-1273576180/Mills_and_1000G_gold_standard.indels.vcf.gz'}, u'aliases': {u'snpeff': u'GRCh38.86', u'human': True, u'ensembl': u'homo_sapiens_merged_vep_95_GRCh38'}}, u'validate': {u'fp': None, u'fn': None, u'tp': None, u'summary': None}, u'config': {'resources': {u'default': {'cores': 1, 'jvm_opts': ['-Xms1000m', '-Xmx3072m'], 'memory': '3072M'}}, u'algorithm': {u'exclude_regions': [], u'min_allele_fraction': 10, 'num_cores': 1, u'vcfanno': [], u'variantcaller': u'gatk-haplotype', u'validate_regions': None, u'tools_off': [u'gemini', u'contamination', u'peddy'], u'variant_regions_merged': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-265338074/cleaned-variant_regions-merged.bed', u'ensemble': u'{"numpass": 2}', u'variant_regions': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/-265338074/cleaned-variant_regions.bed', u'coverage_interval': u'amplicon', u'tools_on': [u'gvcf'], u'validate': None, u'callable_regions': u'/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/1663c452-f25c-407a-850b-949763fdafd3/call-batch_for_ensemble/inputs/944175185/testingVC-analysis_blocks.bed', u'effects': False}}, u'resources': {u'default': {'cores': 1, 'jvm_opts': ['-Xms1000m', '-Xmx3072m'], 'memory': '3072M'}}, u'metadata': {u'phenotype': u'', u'batch': u'testingVC'}}]

When trying to run the same analysis with 4 callers ([gatk-haplotype, strelka2, freebayes, samtools]) and the corresponding jointcallers and ensemble mode (numpass: 3), the outcome is a different error:
Traceback (most recent call last):
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/tools/bin/bcbio_nextgen.py", line 223, in <module>
    runfn.process(kwargs["args"])
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/distributed/runfn.py", line 57, in process
    out = fn(*fnargs)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/utils.py", line 55, in wrapper
    return f(*args, **kwargs)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/distributed/multitasks.py", line 396, in run_jointvc
    return joint.run_jointvc(*args)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/variation/joint.py", line 64, in run_jointvc
    joint_out = square_batch_region(data, ready_region, [], [d["vrn_file"] for d in items], out_file)[0]
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/variation/joint.py", line 179, in square_batch_region
    _square_batch_bcbio_variation(data, region, bam_files, vrn_files, out_file, "square")
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/variation/joint.py", line 235, in _square_batch_bcbio_variation
    do.run(cmd, "%s in region: %s" % (cmd, bamprep.region_to_gatk(region)), env=bcbio_env)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/provenance/do.py", line 26, in run
    _do_run(cmd, checks, log_stdout, env=env)
  File "/export/home/ncit/external/a.mizeranschi/bcbio_nextgen/anaconda/lib/python2.7/site-packages/bcbio/provenance/do.py", line 106, in _do_run
    raise subprocess.CalledProcessError(exitcode, error_msg)
subprocess.CalledProcessError: Command 'set -o pipefail; bcbio-variation-recall square -Xms1000m -Xmx3072m -XX:+UseSerialGC -c 1 -r chr7:1-141973873 --caller samtools /export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/5d82031f-4018-45c9-9e35-99a395d2a24a/call-jointcall/shard-3/wf-jointcall.cwl/fadbfa37-c1d1-4689-a3d1-c5aa3fd4b415/call-run_jointvc/shard-0/execution/joint/samtools/chr7_1-141973873/testingVC-samtools-chr7_1-141973873.vcf.gz /export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/5d82031f-4018-45c9-9e35-99a395d2a24a/call-jointcall/shard-3/wf-jointcall.cwl/fadbfa37-c1d1-4689-a3d1-c5aa3fd4b415/call-run_jointvc/shard-0/inputs/-1010179002/hg38.fa /export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/5d82031f-4018-45c9-9e35-99a395d2a24a/call-jointcall/shard-3/wf-jointcall.cwl/fadbfa37-c1d1-4689-a3d1-c5aa3fd4b415/call-run_jointvc/shard-0/execution/joint/samtools/chr7_1-141973873/testingVC-samtools-chr7_1-141973873.vcf-inputs.txt
Picked up _JAVA_OPTIONS: -Djava.io.tmpdir=/export/home/ncit/external/a.mizeranschi/automated-VC-test/testingVC-merged/work/cromwell_work/cromwell-executions/main-testingVC-merged.cwl/5d82031f-4018-45c9-9e35-99a395d2a24a/call-jointcall/shard-3/wf-jointcall.cwl/fadbfa37-c1d1-4689-a3d1-c5aa3fd4b415/call-run_jointvc/shard-0/tmp.974eea3b
               bcbio.variation.recall.main.main
                                            ...
              bcbio.variation.recall.main/-main    main.clj:  30
              bcbio.variation.recall.main/-main    main.clj:  33
           bcbio.variation.recall.main/-main/fn    main.clj:  34
                             clojure.core/apply    core.clj: 665
                                            ...
            bcbio.variation.recall.square/-main  square.clj: 315
            bcbio.variation.recall.square/-main  square.clj: 343
     bcbio.variation.recall.square/combine-vcfs  square.clj: 290
bcbio.variation.recall.square/sample-to-bam-map  square.clj: 259
                    bcbio.run.fsp/add-file-part     fsp.clj:  35
                       bcbio.run.fsp/split-ext+     fsp.clj:  14
java.lang.NullPointerException:
' returned non-zero exit status 1

Hi @amizeranschi!
I think joint genotyping of many samples and ensemble calling are two different stories. You either do joint genotyping for > 100 samples with gatk or freebayes, or combine callers for a few samples maximum.
With many variant callers you can tune precision/sensitivity when you are working with individual samples or trios. Joint calling is for very large cohorts - here you are using just one tool to call, and then combine calls with joint genotyping.
Sergey

Hi Sergey,
Thanks for your answer, but I'm not sure I understand 100%. Why can't we have both joint genotyping and creating an ensemble VCF file as well, at the end?
Would it not make sense to run joint genotyping with two callers (e.g. gatk and freebayes), produce a joint VCF file from each caller, and then create a consensus (ensemble) VCF file from those single-caller VCF files? Wouldn't this be similar to what was done in the past with ensemble calling on pooled samples, before joint genotyping was introduced for large cohorts (>100 samples)?

I forgot to add, this setup (joint VC with ensemble VCF creation at the end) is already working in bcbio when not using CWL. The errors reported here only seem to happen when using CWL.
The only apparent problem with joint genotyping + ensemble calling (when not using CWL) is that the VCF flag CALLERS also lists the joint callers along with the variant callers (e.g. strelka2-joint along with strelka2), as I mentioned in https://github.com/bcbio/bcbio-nextgen/issues/2688#issue-412394726. It would be great if that could be fixed as well, so that the joint callers don't get listed.

Thanks for this really great discussion. I'm agreed with Sergey's assessment that joint calling + ensemble is not a current focus of bcbio. Practically, I'd recommend sticking with a single joint calling germline approach with GATK4 for a few reasons:

The GATK4 approach is well validated, performant and freely available. We haven't been working on the other joint methods, which were more useful in the past when GATK was restricted access.
If you have enough samples to joint call with, the development focus should be on making that as fast and scalable as possible.
It's very difficult to find good large datasets for validation of joint ensemble calling. We don't currently have a good sense whether a joint approach helps and the ensemble method hasn't been validated and tuned for large populations.

Is ensemble joint calling providing variants that a single GATK4 run is missing? If so, it would be nice to formalize this and figure out how best to support and improve it. Thanks again for the thoughts and suggestions.

Thanks for the reply. In past experiments I have found variants that seemed to be true positives and were missed by individual tools (incl. HaplotypeCaller), but found by others and an ensemble approach with e.g. 3 out of 5 tools produced a better set of high-confidence variants compared with what each individual variant caller came up with. I'm afraid I don't have a reference or any more details about this at the moment, but this is the reason I was interested in the multi-VC, ensemble approach.
Would there be a need for additional validation to the ensemble approach when using joint calling instead of the old population calling? What would this require, more exactly?
I see your point about the runtime and scalability issues when calling variants on a large numbers of samples with multiple tools. However, I was hoping to leave this worry up to the researchers themselves. For those with enough time and resources on their hands, an ensemble approach might just provide a set of higher-confidence variants when identified with multiple tools, compared to putting all your "trust" into a single tool.

As a side question, what would be the limit in terms of number of samples, for using population calling instead of joint calling? The bcbio documentation states Joint calling is only needed for larger input sample sizes (>100 samples), otherwise use standard pooled Population calling.
Would bcbio using CWL be able to parallelize population calling for a large number of samples, using the two settings nomap_split_size and nomap_split_targets? What could be a good strategy for doing this? And would ensemble, multi-tool calling still work with standard population calling instead of joint calling?

Thanks for all this helpful discussion. I definitely agree that there is potential benefit to ensemble methods. So far we haven't had a good dataset with truth calls to demonstrate that it helps enough to overcome the investment in both computational time running multiple callers and development time in tuning and tweaking ensemble calling on large runs. Ensemble output also has the practical downside of having non-harmonized VCFs since the calls come from multiple callers, which requires additional work. We just haven't had the time yet to validate and confirm larger population ensemble calling with CWL; hope this helps explain the current state.
Pooled calling might work better practically for ensemble if you don't have very large sample sizes. It does suffer from the same scientific issue of not being tuned and optimized, since we've mostly focused ensemble testing on smaller pools where you don't have the benefit of informing from a larger sample population as part of the calling algorithm.
Sorry to not have this finished and fully validated, and thanks again for the discussion.

Thanks everyone! Looks like the suggestion to stick with joint calling with GATK is the way to go here. Please reopen if this isn't going to work for you all.


Set python_requires >=3.5 in setup.py

https://packaging.python.org/tutorials/distributing-packages/#python-requires

Done. In fact, the setup.py line in question currently says:
python_requires='>=3.6',


Limit Rollup Job to Record Types

Is there anyway to limit a rollup job to certain record type of an object for the initial job? We have about 80,000 account records that will be checked against when I create a rollup job which will bog down our integration with our other CRM. This would only affect the initial run as these records wouldn't meet the criteria in future jobs. I don't think this is possible but wanted to check. Thank you.

Click 'Calculate' and you get a box where you can type the WHERE clause of an SOQL query.... so in your case you could use WHERE RecordType.Name = 'Record Type Name Here' for example, and that should do what you're looking for.

Click 'Calculate' and you get a box where you can type the WHERE clause of an SOQL query.... so in your case you could use WHERE RecordType.Name = 'Record Type Name Here' for example, and that should do what you're looking for.

I've tried this with both RecordType.Name & RecordType.Id and neither are working. The job will run but it will not complete. If I go to the Lookup Rollup Calculate Jobs tab several hours later, the job I created is still there.

So i removed the WHERE clause and just used RecordType.Name = 'Commercial' and that worked. Thanks for the help ScubaJimmE


Outdated repositories (jcenter)

Getting this error message, when trying to run it:

A problem occurred configuring project ':react-native-android-location-enabler'.
Could not resolve all files for configuration ':react-native-android-location-enabler:classpath'.
Could not find bundletool.jar (com.android.tools.build:bundletool:0.1.0-alpha01).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/bundletool/0.1.0-alpha01/bundletool-0.1.0-alpha01.jar
Could not find manifest-merger.jar (com.android.tools.build:manifest-merger:26.1.0).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/manifest-merger/26.1.0/manifest-merger-26.1.0.jar
Could not find ddmlib.jar (com.android.tools.ddms:ddmlib:26.1.0).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/ddms/ddmlib/26.1.0/ddmlib-26.1.0.jar
Could not find dvlib.jar (com.android.tools:dvlib:26.1.0).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/dvlib/26.1.0/dvlib-26.1.0.jar
Could not find common.jar (com.android.tools:common:26.1.0).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/common/26.1.0/common-26.1.0.jar
Could not find aapt2-proto.jar (com.android.tools.build:aapt2-proto:0.1.0).
Searched in the following locations:
https://jcenter.bintray.com/com/android/tools/build/aapt2-proto/0.1.0/aapt2-proto-0.1.0.jar

Had this issue too, #20 did the trick

Fixed release will be available soon.
Sorry for the late.

v1.0.9 has been released, thx for the PR.


Add support for user-land classname prop

At the moment it is not possible to provide a className for the component to apply, as the outer div uses a hard-coded className value.
I have updated this so that, with no user-provided className prop it behaves as before, but with a className prop both outer styles will be applied

I will take a look at this after the holidays. Thanks for the submission.


Python2.7 dependency issue

cfn-lint version: 0.29.4
Hi,
When installing a project that has cfn-lint as a dependency (moto) using Python2.7, I'm getting this error:
Searching for networkx~=2.1
Reading https://pypi.org/simple/networkx/
...
Best match: networkx 2.4
...
NetworkX 2.3+ requires Python 3.5 or later (2.7 detected).

For Python 2.7, please install version 2.2 using:

$ pip install 'networkx==2.2'

It looks like this is due to incorrect usage of the ~= operator in setup.py:
'networkx~=2.4;python_version>="3.5"',
'networkx~=2.1;python_version<"3.5"'

This semantic has the same outcome for both python versions - use any version that's 2.x, but lower than 3.x.
IMO, this should say:
'networkx~=2.4;python_version>="3.5"',
'networkx<=2.2;python_version<"3.5"'

NetworkX 2.2 is the latest version that supports Python2: https://networkx.github.io/documentation/networkx-2.2/news.html
Happy to create a PR for this, if it's an acceptable change?

Some more information:
The issue can be reproduced by running the following command:
python setup.py sdist

The issue goes away when I pin cfn-lint to an older version, i.e. "cfn-lint>=0.4.0,<=0.28.3", (which was the last release before the networkx dependency was introduced

Is there a way for networkx itself to prevent networkx 2.3+ installations through Python 2? That could also theoretically solve this for all networkx dependents

@bblommers I think that works for me if you want to submit it.


docs(polygon): fix styling

Does any other open PR do the same thing?
Nop
What issue is this PR fixing?
None
How did you test this PR?
I clicked on "Preview" in github

hi @BrodaNoel 👋 Thanks 👍


Feature/metrics catalogue

Motivation
This PR introduces a dependency on metrics-catalogue, which serves a few purposes:

It procedurally generates a metrics-core compatible set of trait implementations based on a simple hierarchical struct definition of metrics. This allows the Stats struct to be single source of truth, regardless whether they were updated using directly on the struct or via the metrics macros
It procedurally generates a catalogue of macros, preventing typos & replacing the need for a manually maintained version, such as the one in metrics::names.
It introduces a Histogram container with fixed windowing, preventing the drain behavior as seen in prometheus-metrics-exporter. This allows multiple prometheus clients to scrape simultaneously without missing samples.

Note:
All counters currently have a _total postfix. For simplicity's sake, I've removed those. Unless there's a significant reason to keep these?
Test Plan
The changes can/should be tested in multiple ways:

HTTP GET request on the metrics endpoint, typically localhost:9000
Run a local prometheus + grafana & inspect the dashboard. Everything should reported as before

Related PRs

https://github.com/AleoHQ/snarkOS/pull/879

Closing the PR as it's either no longer applicable to testnet2 or would require a rewrite (in which case, feel free to reopen once rebased).


Set profile once  has been initialized

I hate to say it, but I tried importing the same 300 household scenario again and, despite the import form showing "edsn_e1a", the base load got saved with "anonimous_base_load_1".
A previous version of the pull request #773 (2ba2ed5) did work, so I resurrected one of the lines which was removed from the merged version.
@grdw Does this look right to you?

Yes, I'm still convinced that this needs to change from the root down but for now this will do.


raftstore: support changing label key for replication

What is changed and how it works?
This PR supports changing label key at runtime.
PD may not specify label key until replication mode is DR_AUTO_SYNC. Even replication mode is configured, label key can be wrong and need to be corrected. So loading label value during starting is not a feasible solution.
This PR caches all label key-value instead. So even PD change label key, new group ID can be still be re-calculated instead of loading all from PD again.
Check List
Tests

Unit test
Integration test

Release note

No release node.

Should we also support the change of each store's labels?

No, we don't support label value update.


Custom Insight Instance

We need to run our own instance of Insight.
We need an AWS machine for this.
Insight runs on top of a Bitcore Node, which requires 200GB or more of HD and 8GB or more of RAM.
We should rent a machine with at least 300GB of HD and 16GB of RAM to be safe. Maybe need to increase the HD space in six to twelve months, but the RAM will probably do.
What AWS machine would be good for this?
I'm looking at t2.xlarge and i3.large machines, but maybe should research a bit on it.
Maybe there are more cost-effective solutions to in-house hosting insight instances?

This is working in the EC2 machine, although I still need to configure it as a daemon. I have written some configuration steps in the Wiki. The idea is to configure Terraform for this (probably another ticket?)

@pmosse yeah. let's close this one once you're confident the instance is running well and we know how to run it as a daemon.
I'll create a separate issue in the terraform repo to track that part.


TSLint works on the command line - gulp-tslint returns TypeError: Cannot read property 'getFullWidth' of undefined

In trying to get this setup, I am getting an error in gulp-tslint, that I do not get using tslint on the command line.
This is the sub job that runs the Typescript compile and TSLint
module.exports = function (gulp, PlugIns, Settings) {
return function () {
    gulp.src(['./app/Modules/**/*.tsx'])
	    .pipe(PlugIns.plumber())
	    .pipe(PlugIns.debug())
    	.pipe(PlugIns.typescript())
    	.pipe(PlugIns.tslint( {
			configuration: {
				rules: {
					"class-name": true,
					"curly": true,
					"eofline": true,
					"indent": [
						true,
						"tabs"
					],
				}
			}
		}))
    	.pipe(PlugIns.tslint.report("stylish"))
    	.pipe(gulp.dest(Settings.Destination.TSCompiled))
        ;
    }
};

My Test file that should have errors
class Greeter {
    constructor(public greeting) { }
    greet() {
        return "<h2>" + this.greeting + "</h2>";
    }
    nogreet()
    {
return 'Not ' + this.greeting;
}
};

var greeter = new Greeter("Hello, world!");

gulp-tslint error generated when running gulp:
gulp
[18:20:20] Using gulpfile ~\Development\gulpfile.js
[18:20:20] Starting 'TypeScript'...
[18:20:20] Finished 'TypeScript' after 569 ms
[18:20:20] Starting 'default'...
[18:20:20] Finished 'default' after 7.84 ms
[18:20:20] gulp-debug: app\Modules\Cars\car.tsx
[18:20:20] gulp-debug: 1 item
~\Development\node_modules\tslint\lib\language\walker\ruleWalker.js:18
        this.limit = this.sourceFile.getFullWidth();
                                    ^
TypeError: Cannot read property 'getFullWidth' of undefined
    at EnableDisableRulesWalker.RuleWalker [as constructor]
(~\Development\node_modules\tslint\lib\language\walker\ruleWalker.js
:18:37)
    at EnableDisableRulesWalker.SkippableTokenAwareRuleWalker [as constructor] (
~\Development\node_modules\tslint\lib\language\walker\skippableTokenAwareRuleWalker.js:11:16)
    at new EnableDisableRulesWalker (~\Development\node_modules\tslint\lib\enableDisableRules.js:13:16)
    at Linter.lint (~\Development\node_modules\tslint\lib\tslint.js:16:27)
    at ~\Development\node_modules\gulp-tslint\index.js:96:34
    at respond (~\Development\node_modules\rcloader\index.js:73:7)
    at respond (~\Development\node_modules\rcfinder\index.js:140:7)
    at ~\Development\node_modules\rcfinder\index.js:124:17
    at ~\Development\node_modules

However, running the tslint from the command line (in the same directory as gulp), the coding issues are returned.
tslint -c tslint.json app\Modules\Cars\Greet.tsx
app/Modules/Cars/Greet.tsx[3, 5]: default access modifier on member/method not a
llowed
app/Modules/Cars/Greet.tsx[6, 5]: default access modifier on member/method not a
llowed
app/Modules/Cars/Greet.tsx[2, 17]: 'greeting' cannot be declared in the construc
tor
app/Modules/Cars/Greet.tsx[12, 5]: unused variable: 'greeter'
app/Modules/Cars/Greet.tsx[12, 1]: forbidden var keyword
app/Modules/Cars/Greet.tsx[7, 5]: misplaced opening brace
app/Modules/Cars/Greet.tsx[8, 8]: ' should be "
app/Modules/Cars/Greet.tsx[2, 32]: expected parameter: 'greeting' to have a type
def
app/Modules/Cars/Greet.tsx[3, 11]: expected call-signature: 'greet' to have a ty
pedef
app/Modules/Cars/Greet.tsx[6, 13]: expected call-signature: 'nogreet' to have a
typedef
app/Modules/Cars/Greet.tsx[12, 12]: expected variable-declaration: 'greeter' to
have a typedef

Can you post the version of tslint at ~\Development\node_modules\tslint\ and the version of TypeScript used (perhaps located in ~\Development\node_modules\typescript)? Usually this kind of error happens with a tslint and TypeScript version mismatched. Try to update them to the latest versions.

├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ │ ├──<EMAIL_ADDRESS>│ │ └──<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>└──<EMAIL_ADDRESS>These are local to the project.

Can you post the output of tslint -v? Note that running tslint from the command line may use a different version than what is under node_modules of the current directory.
For example:
nawi ~/dev/gulp-tslint cat node_modules/tslint/package.json | grep version
  "version": "3.2.1"
nawi ~/dev/gulp-tslint tslint -v
3.1.1
nawi ~/dev/gulp-tslint which tslint
/usr/local/bin/tslint

~\Development>cat node_modules/tslint/package.json | grep version
"version": "3.2.1"
node_modules.bin\tslint -v
3.2.1

Hi, sorry to both again, but I meant the output of tslint -v, not node_modules.bin\tslint -v (I'm not quite sure if they're the same thing for you).

Sorry, running just tslint gives an error as I  did  not install it globally, it is only in the project directory which is why I added the second  line with the node_modules.bin\tslint -v.

Can you try again with the latest versions of gulp-tslint and tslint?

Using the latest version, 3.7.4 has this problem solved. It is working properly.


Plot style

command plt.style.use('MSUStyle') gives error. Can't find MSUStyle.

Fixed. Copy the styles into the matplolib folder at during the installation phase of Sarkas


Targets-ify this repository

We should focus on converting this project to targets before we continue to develop anymore. There is enough interaction across files that it would be useful to get this done before we start plugging in our code to the FC system.

Quick progress report:

API pull portion of the workflow has been converted to targets, but we still need to figure out how to append the data to the historical data.
Will move on to converting the QAQC portion of the workflow to targets in the next days.

Update:

QAQC portion has been converted to targets. Tomorrow I will open up a branch in the main repo to see how bad the merge is going to be and then fix that.
Will focus on appending process in the next days.

Sounds great, Juan!


DONT MERGE build: correct go module to v2

TODOs:

[ ] find a way to not break all the generated go clients

This change corrects the go module of zitadel. For versions > 1 the module must include the major version which is github.com/zitadel/zitadel/v2 in our case.
As it's currently not possible to import zitadel in go projects the change is not breaking.
closes https://github.com/zitadel/zitadel/issues/5575

TODOs:

[ ]  find a way to not break all the generated go clients

@adlerhurst which generated go clients would break? No go project has ever been able to import v2 using the import path github.com/zitadel/zitadel, right?

@adlerhurst which clients would break? AFAIU, the pkg folder at v2 is only importable by the zitadel core itself, not by clients or client libraries. Am I missing something?
@livio-a maybe you can also help me understand the issue or point me to valid test cases?
I don't see an issue with merging the new PR https://github.com/zitadel/zitadel/pull/8649 which has an up-to-date base branch.

closed in favour of https://github.com/zitadel/zitadel/pull/8649


Update to openai>1 to fix OpenAI evals

HarmBench's requirements.txt specifies openai>1, but the code actually uses pre-1 APIs (so running OpenAI evals is broken). This PR updates the code for openai v1 API.

lgtm. thanks for the fix


mgmt lite, fix devhub swagger

Description
fix according to swagger fix https://github.com/Azure/azure-rest-api-specs/commit/5cc8f4adf6717a00afda1017f31da3f0b3245451
Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[ ] The pull request does not introduce [breaking changes]
[ ] CHANGELOG is updated for new features, bug fixes or other significant changes.
[ ] I have read the contribution guidelines.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-devhub


Protractor idles until mouse move because web timers

Hi!
I've a really extrange problem. I'm working in a web who use timers to control the user activity and to show a modal if the user didn't move the mouse or do anything in the web in a time.
Because of that timer all my tests developed with Protractor idles until I move the mouse over the browser selenium has opened. If I don't move the mouse the test give me a timeout exception.
For example, with this code:
` this.When(/^go to home page$/, function(next){
browser.get(browser.params.urlServidor + '/').then(function(){
browser.driver.manage().window().maximize();
expect(element(by.id("contentPaso")).getText()).to.eventually.contains("Are you client?").and.notify(next);
}); `
If I move the mouse, works fine: load the page, waits until the text appear and go to the next step. I I don't move the mouse I get a timeout.
I've found one issue in stackoverflow similar like this http://stackoverflow.com/questions/36000139/selenium-webdriver-idles-until-mouse-is-moved
Did you have any idea? I'm watching how to disable the timer calling a javascript from my tests.
Regards

Node Version: v5.0.0
Protractor Version: 4.0.2
Browser(s): Chrome
Operating System and Version Linux 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

My configuration file:
`exports.config = {
	allScriptsTimeout: 70000,

	specs: [
	       'features/*.feature'
	],

	capabilities: {
		'browserName': 'chrome',
	//	'browserName': 'firefox',
	//	'marionette': true
		'chromeOptions': {
        'args': ['--start-maximized']}
	},

	params: {
		urlServidor: 'http://cotizadorautos-acep-web.clouddes.mutua.es/seguros-coche/calcular'
	},

	seleniumAddress: 'http://<IP_ADDRESS>:4444/wd/hub',

	framework: 'custom',

	frameworkPath: require.resolve('protractor-cucumber-framework'),

	cucumberOpts: {
		require: 'features/step_definitions/**.js',
	    format: 'pretty',
	    verbose: 'false',
			profile: false
	},

	rootElement: '*[ng-app]',

	resultJsonOutputFile: '../../target/cucumber_report.json'

};`

I think you will find the same answer as in the SO thread that you posted: It turns out there was something polling timeout repeatedly, which was causing this.
Before your getText(), protractor will automatically wait until outstanding timeouts have finished so that it knows the page has settled.

You should be able to use actions to move the mouse.  Also, please ask support questions on stack overflow.  The github page is for bugs/feature requests


Improve Deprecations and Mark wl_pointer::axis_discrete as Deprecated

I noticed wl_pointer::axis_discrete isn't marked as deprecated. As far as I can tell, all other depreciations are on objects or protocols, not on a method/event (and even arguments like in wl_output::mode can be deprecated although they are harder to mark because you need the context provided in the description, but it would be nice to mark them too), it would be nice to support these as well.

I feel like it would be better to have the protocols themselves contain deprecations, it'll be more maintainable and help other documentation sites/reading the protocols in text, do you know if there's an upstream issue/proposal for it?

See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/329

Yeah, the depreciations should just be in the XML, the current solution that I did is only meant to be a stopgap for now, and that's also why it's so bare bones.


Change Map function logic

hi
In new approach I change sign function and now we can use like this :
des := Map[struct{ Children []testClass2 }](source)

Hi.
I'm super glad, that people still find this useful that I created so many years ago to address a problem I had back then.  But I haven't been coding in go for 5 years, so I'm not really maintaining this anymore.

So, can you please make me a container, I have some ideas for  this repo that can be useful ...
Thanks

@stroiman Your package is really useful. Can you really make @MohammadMobasher mantainer, so it will continue to live.
@MohammadMobasher Did you manage to find another package like this, that is still alive?

Hi, I never saw the reply on Oct. 26th. But can't you just fork it, and maintain it under a different name?
Last time I coded in go, package references were just github repos, so you'd just reference a different repo. But there's better package management now, right?

But I'm grateful you find it useful.

@stroiman Thank you for your reply. Forking isn't the answer, because until google gets into speed with the newest popular fork, you end up with a forest of forks, each with different fixes, with no hope to consolidate.
Anyway, I think that there is feature rich alternative "github.com/devfeel/mapper" alternative.
Thank you, and all the best with your endeavors.


2.10.1 with distil-whisper/distil-small.en throws error

System Info
2.10.1
Environment/Platform

[X] Website/web-app
[ ] Browser extension
[ ] Server-side (e.g., Node.js, Deno, Bun)
[ ] Desktop app (e.g., Electron)
[ ] Other (e.g., VSCode extension)

Description
When using transformers.js 2.10.1 with model distil-whisper/distil-small.en and word level timestamps, it fails to complete and error is logged in console:
8b6e3106-c192-4a81-a0cf-225723d7cde0:70 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'slice')
    at 8b6e3106-c192-4a81-a0cf-225723d7cde0:70:30621
    at Array.map (<anonymous>)
    at 8b6e3106-c192-4a81-a0cf-225723d7cde0:70:30600
    at Array.map (<anonymous>)
    at Function._extract_token_timestamps (8b6e3106-c192-4a81-a0cf-225723d7cde0:70:30482)
    at Function.generate (8b6e3106-c192-4a81-a0cf-225723d7cde0:70:30012)
    at async Function._call_whisper (8b6e3106-c192-4a81-a0cf-225723d7cde0:73:10097)
    at async 2.10.1-words-worker.js:50:16

Reproduction
test.html
<script>
new Worker("worker.js", {type:"module"});
</script>

worker.js
import { env, pipeline } from "https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>
const file = "tos.pcm";
const model = "distil-whisper/distil-small.en";
const buffer = new Float32Array(await (await fetch(file)).arrayBuffer());
const pipe = await pipeline("automatic-speech-recognition", model);
const result = await pipe(buffer, {num_beams:1, do_sample:false, temperature:1,
	top_k:0, chunk_length_s:30, stride_length_s:5, return_timestamps:"word"});
console.log(JSON.stringify(result));

all filles attached assets.zip

@jozefchutka in the meantime, you can override the alignment heads:
const result = await pipe(buffer, {
    num_beams:1, do_sample:false, temperature:1, top_k:0, chunk_length_s:30, stride_length_s:5,
    return_timestamps:"word", alignment_heads: [[2, 2], [3, 0], [3, 2], [3, 3], [3, 4], [3, 5]]
});

(these were mostly chosen randomly, so to improve the quality, you can play around with other values). As described here:

If you fine-tuned your own checkpoint, you may need to inspect the cross-attention weights to find the appropriate layers and attention heads.

... which we should be doing


Leads have not source_id field

I've seen that the SDK doesn't have source_id field for leads (it's not enabled). You just need to enable it in the LeadsService class.
Thank you!

It's possible with the latest release 1.1.1.


Unexpected space character between function call and tagged literal

Assume the following code being compiled with target es6 or esnext:
const StyledDiv = styled.div`
	background: red
`

Expected behavior:
const StyledDiv = styled_components_1.default('div')`
	background: red
`

Actual behavior:
const StyledDiv = styled_components_1.default('div') `
	background: red
`

Because of the space character between function and template literal ...('div')█`... StyledComponents don't work

What do you mean by "StyledComponents don't work"?

My apologies! there was an error in my own setup. Probably a styled-components <-> react version incompatibility. Maybe I wasn't using the latest version for either of them and thus tagged literals weren't behaving as expected.

It looks like this is definitely a bug with the version 3.3.3333 while exporting to es2017
function test(...args) {}

const t = test`template literals`;

compiles to
function test(...args) { }
const t = test `template literals`;

That's just how our compiler formats its output, and that's not semantically different either, so it's not a bug.

There is a space between test and template literals in the output. It won't work as tagged template literal.

Can you open a separate issue and show it not working in a JavaScript runtime?

Ok, you're right, it works. I didn't know a space is allowed here. At least I learned something 😅. I was fighting with a bug related to that this morning - even this simple exemple didn't work - and after reopening the site to see the bug again, no more bug 🧐⁉ Sorry for the waste of time.


Update go version for DWD check-vul job

/kind enhancement
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:

/kind enhancement


Add ESLint

You can use same Logux config as Amplifr

Hi, @ai !
Thanks for your Issue. ESLint rules are added. I'm using https://github.com/logux/eslint-config-logux.
Thanks!


swc can not compile some legal js code when parser set to 'typescript'

Describe the bug
swc failed to compile the following code under the typescript mode.
Input code
const r=n=>{return true?(true):t=>{}}

Config
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true,
      "decorators": true,
      "dynamicImport": true,
      "decoratorsBeforeExport": true
    },
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true,
      "react": {
        "pragma": "React.createElement",
        "pragmaFrag": "React.Fragment",
        "runtime": "automatic", // or classic
        "throwIfNamespace": true,
        "useBuiltins": true,
        "development": true
      }
    },
    "target": "es2015",
    "loose": true,
    "externalHelpers": true,
    // Requires v1.2.50 or upper and requires target to be es2016 or upper.
    "keepClassNames": false
  }
}

Playground link
https://play.swc.rs/?version=1.2.197&code=H4sIAAAAAAAAA0vOzysuUSiyzbO1qy5KLSktylMoKSpNtdcAkZpWJUDh2louAL2McbkmAAAA&config=H4sIAAAAAAAAA0WNSwrDMAxE76J1ts0id%2BghjKsEF%2F%2FQKBBjfPfawSU7aebpqdIXlrZK2QhYxoQS1Vy0kZbMsOKy0kKKHu3Gg1tfjBysHWG8eudTAs92oeCi28sw2RSyMPBUJh7%2BT7YuCulzjqDez27hSu1xzDuH9wRVTm4%2FOkwQUrUAAAA%3D
Expected behavior
swc should be able to compile this legal js file under ts mode
Actual behavior
throw an error
Version
1.2.197
Additional context
No response

+1 since I think my example could be caused by the same issue.
This is what happens with d3-array dependency cumsum.js file.
playground link: https://play.swc.rs/?version=1.2.198&code=H4sIAAAAAAAAA12OQQqDMBBF957iLxMixUXpopIWN71H0AQETcqYCZbauzdaaaGr%2BcNj3nw73wNFdNYZHiIc%2Bzb2waPlceJRJDOwnUpsMziJZ4G8EDKERlWi952d11hnQjYyedyGYOLp2BCZx8FRGEVmwC775eCgtQZnheu97TZyRYK%2BQKwflIZKWBZUcmPnf%2FaxiLT3UGqvOsnvlayL1xs7ixJh5gAAAA%3D%3D&config=H4sIAAAAAAAAAzXIwQmAMAwF0F3%2BuRN0B4cIMYIituSnYCndXT14e7yBg4o8UMVp%2Fon9CrmREb0a1fcaSAi%2BtclJS1hNi0sUJ3J4szkTWJqrLVL%2FewBbolr5WgAAAA%3D%3D

I also encountered this issue, and I noticed this was introduced in SWC v1.2.146

v1.2.145
v1.2.146

 playground
 playground

The same thing started to happen here by upgrading the recharts lib which is dependent on d3-* libs.
Pretty much the same error as @bernardocorbella described.


Feature Request: adaptive image output (as dispatcher option maybe?)

Hi Cody,
Great work! Munee has become a standard asset in my projects very quickly.
Previously I experimented with http://adaptive-images.com/ to serve appropriately sized images to devices. I'm trying to find a way to replicate this with munee.
In short: I'd like to be able to set munee to an exact width (max device screen width) and have it resize all image output to that size. Would a dispacher option work for that?

Hmmm, what if you added the following right after you opened up <head>?
<script>document.cookie = "maxwidth=" + screen.width</script>

And then added the following to htaccess:
RewriteCond %{QUERY_STRING} limitscreen=true [NC]
RewriteCond %{HTTP_COOKIE} maxwidth=(\d+) [NC]
RewriteRule \.(?:jpe?g|gif|png|bmp)$ /$1?resize=w[%1] [QSA,NC]

Then in body, assuming bla.jpg is a wallpaper of 1920x1080:
<img src="bla.jpg?limitscreen=true">


LINQ use's default serializer for parameters

The LINQ query generation should use the user specified serializer for the parameters when generating the query. This will ensure that any custom conversion are honored for the parameters. This was fixed for query text via PR 576
The other option is for LINQ to support parameterized quiries, and then the parameter handling can be done by the existing query logic.

Just ran (if I understood the issue correct) into the same problem. Here is an example, that illustrates my case. It uses a custom date time converter to write just year, month and day into the JSON. If you try to make a Where() clause on that field you'll get nothing, cause the default serializer is used instead of the specified custom one:
using System;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Cosmos.Linq;
using Newtonsoft.Json;
using Newtonsoft.Json.Converters;

namespace ConsoleApp
{
    public static class Program
    {
        private const string EndPoint = "https://<domain>.documents.azure.com:443/";
        private const string AuthKey = "<key>";

        public async static Task Main()
        {
            var options = new CosmosClientOptions
            {
                SerializerOptions = new CosmosSerializationOptions
                {
                    PropertyNamingPolicy = CosmosPropertyNamingPolicy.CamelCase
                }
            };

            var random = new Random();
            var today = DateTime.UtcNow.Date;

            using (var client = new CosmosClient(EndPoint, AuthKey, options))
            {
                var databaseResponse = await client.CreateDatabaseIfNotExistsAsync("MyContainer");
                var database = databaseResponse.Database;
                var containerResponse = await database.CreateContainerIfNotExistsAsync(
                    new ContainerProperties
                    {
                        Id = "MyStatistics",
                        PartitionKeyPath = "/dayOfEntry"
                    });
                var container = containerResponse.Container;
                var scores = Enumerable.Range(1, 10)
                    .Select(_ => new Player { Timestamp = today.AddDays(random.NextDouble()) });

                foreach (var entry in scores)
                {
                    var _ = await container.CreateItemAsync(entry);
                }

                var query = container
                    .GetItemLinqQueryable<Player>(allowSynchronousQueryExecution: true)
                    .Where(entry => entry.DayOfEntry == today);

                // Expected Query:
                // {{"query":"SELECT VALUE root FROM root WHERE (root[\"dayOfEntry\"] = \"2019-12-10\") "}}
                // Current Query:
                // {{"query":"SELECT VALUE root FROM root WHERE (root[\"dayOfEntry\"] = \"2019-12-10T01:00:00+01:00\") "}}
                var iterator = query.ToFeedIterator();

                while (iterator.HasMoreResults)
                {
                    var response = await iterator.ReadNextAsync();

                    Console.WriteLine($"Found {response.Count} items for {today:yyyy-MM-dd}.");

                    foreach (var item in response)
                    {
                        Console.WriteLine($"   {item.Timestamp}");
                    }
                }
            }
        }
    }

    public class CustomDateTimeConverter : IsoDateTimeConverter
    {
        public CustomDateTimeConverter(string dateTimeFormat)
        {
            DateTimeFormat = dateTimeFormat;
        }
    }

    public class Player
    {
        private const string DayOfEntryFormat = "yyyy-MM-dd";

        public Guid Id { get; set; } = Guid.NewGuid();
        [JsonConverter(typeof(CustomDateTimeConverter), DayOfEntryFormat)]
        public DateTime DayOfEntry => Timestamp.Date;
        public DateTime Timestamp { get; set; }
    }
}

My current workaround would be to never use a custom serializer or add a note, that this field can't be used in LINQ queries as a filter. Hope this can and will be fixed in a future release.

This was an issue in previous versions of the sdk as well. We are in the process of migrating to V3 and were hoping that the improved support for custom serializers would make our usage of Noda Time work in linq queries.

Its already addressed in V3 SDK.

Its already addressed in V3 SDK.

@kirankumarkolli Some better description would be more helpful, not just saying "it's already addressed". By default it is not.

Currently experiencing this issue with 3.19.0.
A custom serializer is used to convert a DateTime to double. Writing works fine. Values are OK in cosmosdb.
But when constructing queries, it doesn't use the serializer and converts the DateTime to a string.
How can we tell the linq query to also use the custom serializer?

We are migrating from V2 of the SDK to V3 (3.21.0) and the following query:
IQueryable<SessionKey> sessions = container.GetItemLinqQueryable<SessionKey>(allowSynchronousQueryExecution: true)
    .Where(o => o.ProcessingTime <= DateTime.UtcNow)

Is now converted into (assuming I'm in UTC+3 time zone):
SELECT VALUE root FROM root WHERE (root[\"ProcessingTime\"] <= \"2021-10-20T15:31:31.7888144+03:00\"

SessionKey.ProcessingTime is decorated with [JsonConverter(typeof(IsoDateTimeConverter))]. When I remove JsonConverter attribute, the query is composed correctly as:
SELECT VALUE root FROM root WHERE (root[\"ProcessingTime\"] <= \"2021-10-20T12:52:47.1161316Z\"


USHIFT-1303: Separate libvirt installation and startup into manage-vm.sh script

To speed up VM creation in the metal-test CI job, it is necessary to run the create-vm.sh scripts in parallel.
The problem is that dnf command executed from within the script corrupts its database when run on parallel.
This change is separation libvirt initialization so that is can be called before the VM creation is triggerred.
P.S. Also removing the obsolte os-type argument of virt-install
Prerequisite for https://github.com/openshift/release/pull/40471

/assign @pmtk

/lgtm


Reverting changes from recent mcode action bug patch

Solves: MH-12252
Reverting changes from recent mcode-action bug fixes, as per the following PRs:

https://github.com/ForAllSecure/mcode-action/pull/21/files
https://github.com/ForAllSecure/mcode-action/pull/20/files

@ethan42 We still have the CLI caching commented out, I presume we should just keep this commented out? Or should we go the next step and actually remove/clean it up?
  // Return cache if available
  // const cachedPath = tc.find(bin, cliVersion, os);
  // if (cachedPath) {
  //   core.debug(`found cache: ${cachedPath}`);
  //   return `${cachedPath}/${bin}`;
  // }


Ingress documentation

Dont know exactly were this documentation should go? Is this generic explanation what we are looking for?

Successfully merging this will close https://github.com/elastisys/compliantkubernetes-kubespray/issues/25, as per discussion with @tordsson.
If someone believes this to be incorrect, a new issue will have to be opened and the acceptance criteria clearly specified.

LGTM. Can you fix the pipeline and merge?


Alternatives to BdvRealSourceToVoxelImageExporter

@tischi You removed 'BdvRealSourceToVoxelImageExporter' in this commit: https://github.com/tischi/imagej-utils/commit/f8ca1616f7f918a27cabed5b7be02f6cb7d34a1a
Is there a newer alternative for writing a certain level of a bdv format file to tiff etc?

@K-Meech Sorry, may have been by accident. Please put it back if you need it.


kubernetes + webhook + hotreload + error locating command

Hi everyone!
I found a weird behavior that should works (at least it's working docker-compose and volumes) with kubernetes!
I'm trying to have pods with webhook and be able to hot-reload the hooks and scripts. 😄
With docker-compose and volumes, it's working but now I want to step up a little bit with kubernetes!
In this issue, normally you'll have everything to reproduce it on a k8s cluster!
So I got a simple setup with this manifest:
Manifest:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: d-webhook
spec:
  replicas: 1
  selector:
    matchLabels:
      app: a-webhook
  template:
    metadata:
      labels:
        app: a-webhook
    spec:
      containers:
      - name: webhook-development
        imagePullPolicy: Always
        image: dalongrong/almir-webhook-curl
        ports:
        - containerPort: 9000
---
apiVersion: v1
kind: Service
metadata:
  name: s-webhook-development
spec:
  type: LoadBalancer
  ports:
  - port: 9000
    targetPort: 9000
  selector:
    app: a-webhook

And then, I copy scripts and hooks.yaml with kubectl
You'll need the podname sooo:
kubectl get pods -l app=a-webhook -o json | jq -r '.items[].metadata.name'
With the name, you can replace "podname" with the correct name.
Copy the scripts to the pod:
kubectl cp ./scripts podname:/var/ podname
Copy the hooks to the pod:
kubectl cp ./hooks.yaml podname:/etc/webhook podname
hooks.yaml
-   id: ping
    execute-command: /var/scripts/ping.sh
    command-working-directory: ./
    response-message: pong

scripts/ping.sh
#!/bin/sh
echo "pong"

After you executed the two commands, you should have this:
[webhook] 2020/09/15 16:56:59 caught HUP signal
[webhook] 2020/09/15 16:56:59 attempting to reload hooks from /etc/webhook/hooks.yaml
[webhook] 2020/09/15 16:56:59 found 1 hook(s) in file
[webhook] 2020/09/15 16:56:59 	loaded: ping

So, normally it should mean the hook is hot-reloaded and the scripts are located at /var/scripts
If you bash in the pod, you can see the scripts!
And then, you can try to trigger the webhook but first you need to expose the port:
kubectl port-forward service/s-webhook-development 9000:9000

And then on your browser to make it simply, go to : http://localhost:9000/hooks/ping
You should see "pong" BUT on the logs :
[webhook] 2020/09/15 17:09:21 [c8acb1] incoming HTTP GET request from <IP_ADDRESS>:60918
[webhook] 2020/09/15 17:09:21 [c8acb1] ping got matched
[webhook] 2020/09/15 17:09:21 [c8acb1] error parsing body payload due to unsupported content type header:
[webhook] 2020/09/15 17:09:21 [c8acb1] ping hook triggered successfully
[webhook] 2020/09/15 17:09:21 [c8acb1] 200 | 4 B | 68.101µs | localhost:9000 | GET /hooks/ping
[webhook] 2020/09/15 17:09:21 [c8acb1] error locating command: '/var/scripts/ping.sh'

Thanks you for this amazing tool, can't wait to resolve this, I'm having a lot of fun!
I hope I didn't forgot something, normally it should work on your side!
Hope someone could help on this 😃

Should that be kubectl cp -R ./scripts podname:/var/ podname?

What version of webhook are you running?  Can you enable webhook debugging?

Normally, without the -R it should work, cause you copy the whole folder!
At least, it's working like that on my side! 😛

What version of webhook are you running? Can you enable webhook debugging?

It's using the latest of almir/webhook
I'm basically using this Dockerfile: https://github.com/rongfengliang/almir-webhook-curl-demo/blob/master/Dockerfile
I'm gonna enable the webhook debugging and paste the logs!

I also have a most "complex" Dockerfile
FROM joemiller/go-init-sentinel as go-init-sentinel

FROM almir/webhook as webhook
COPY --from=go-init-sentinel /go-init-sentinel /go-init-sentinel
RUN apk update && apk add --no-cache curl

COPY ./scripts /var/scripts
COPY ./hooks.yaml /etc/webhook

EXPOSE 9000

ENTRYPOINT [ "/go-init-sentinel", "-watch=/etc/webhook/hooks.yaml:SIGHUP", "-watch=/var/scripts/:SIGHUP", "--"]

CMD [ "webhook", "-verbose", "-debug", "-hooks=/etc/webhook/hooks.yaml", "-hotreload" ]

So, I've enable the debug, here a hot copy-paste
[webhook] 2020/09/15 17:30:53 [867d14] incoming HTTP GET request from <IP_ADDRESS>:43260
[webhook] 2020/09/15 17:30:53 [867d14] ping got matched
[webhook] 2020/09/15 17:30:53 [867d14] error parsing body payload due to unsupported content type header:
[webhook] 2020/09/15 17:30:53 [867d14] ping hook triggered successfully
> [867d14] GET /hooks/ping
> [867d14] Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
> [867d14] Accept-Encoding: gzip, deflate, br
> [867d14] Accept-Language: en-US,en;q=0.9,fr;q=0.8
> [867d14] Connection: keep-alive
> [867d14] Sec-Fetch-Dest: document
> [867d14] Sec-Fetch-Mode: navigate
> [867d14] Sec-Fetch-Site: none
> [867d14] Sec-Fetch-User: ?1
> [867d14] Upgrade-Insecure-Requests: 1
> [867d14] User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
> [867d14] id:
< [867d14]
< [867d14] pong
[webhook] 2020/09/15 17:30:53 [867d14] 200 | 4 B | 96.303µs | localhost:9000 | GET /hooks/ping
[webhook] 2020/09/15 17:30:53 [867d14] error locating command: '/var/scripts/ping.sh'

From what I saw, it's this line that panic : https://github.com/adnanh/webhook/blob/e6e324235dd142bfa312087d103b16b59e2d647b/webhook.go#L566
I tried to play with the command-working-directory but I failed to have something that works....
When I build the image with the scripts already exists, it's working with the same configuration!
It's just new scripts that failed to be located!

Can you confirm that the file exists in the container/pod?  Can you confirm that the exec bit is set on the script?

I confirm!
I even copied them in two location because I was soooo confused with the situation 😛
/etc/webhook # ls /var/scripts/
addition.sh  create.sh    ping.sh      view.sh
/etc/webhook # ls /etc/webhook/scripts/
addition.sh  create.sh    ping.sh      view.sh
/etc/webhook #

And you confirmed that the script is executable by the user running the webhook process?
If you're willing to hack on webhook, try this:
diff --git a/webhook.go b/webhook.go
index 1af2ce5..4dfdb12 100644
--- a/webhook.go
+++ b/webhook.go
@@ -565,11 +565,11 @@ func handleHook(h *hook.Hook, rid string, headers, query, payload *map[string]in
                // give a last chance, maybe is a relative path
                relativeToCwd := filepath.Join(h.CommandWorkingDirectory, h.ExecuteCommand)
                // check the command exists
-               cmdPath, err = exec.LookPath(relativeToCwd)
+               cmdPath, _ = exec.LookPath(relativeToCwd)
        }

        if err != nil {
-               log.Printf("[%s] error locating command: '%s'", rid, h.ExecuteCommand)
+               log.Printf("[%s] error locating command %q: %s", rid, h.ExecuteCommand, err)

                // check if parameters specified in execute-command by mistake
                if strings.IndexByte(h.ExecuteCommand, ' ') != -1 {

That should include the underlying error from the exec stdlib package.

Alright, let's build the new image and test this.
I've clone the repo and add some part of the original Dockerfile like this:

#   A way to manage signals on containers... so pods
FROM joemiller/go-init-sentinel as go-init-sentinel

# FROM almir/webhook as webhook

#   Edit to test webhook issue 456
FROM        golang:alpine3.11 AS build
MAINTAINER  Almir Dzinovic<EMAIL_ADDRESS>WORKDIR     /go/src/github.com/adnanh/webhook
ENV         WEBHOOK_VERSION 2.7.0
RUN         apk add --update -t build-deps curl libc-dev gcc libgcc

COPY ./master /go/src/github.com/adnanh/webhook

RUN         go get -d && \
            go build -o /usr/local/bin/webhook && \
            apk del --purge build-deps && \
            rm -rf /var/cache/apk/* && \
            rm -rf /go

FROM        alpine:3.11 as webhook
COPY        --from=build /usr/local/bin/webhook /usr/local/bin/webhook
WORKDIR     /etc/webhook
VOLUME      ["/etc/webhook"]

#   Continue my things
COPY --from=go-init-sentinel /go-init-sentinel /go-init-sentinel
RUN apk update && apk add --no-cache curl

COPY ./scripts /var/scripts
COPY ./hooks.yaml /etc/webhook

EXPOSE 9000

ENTRYPOINT [ "/go-init-sentinel", "-watch=/etc/webhook/hooks.yaml:SIGHUP", "-watch=/var/scripts/:SIGHUP", "--"]

# Default command
CMD [ "webhook", "-verbose", "-debug", "-hooks=/etc/webhook/hooks.yaml", "-hotreload" ]

Ok so, here what I got:
/etc/webhook # ls /var/scripts/
addition.sh  create.sh    ping.sh      view.sh
/etc/webhook # ls /etc/webhook/scripts/
addition.sh  create.sh    ping.sh      view.sh
/etc/webhook # cat /etc/webhook/hooks.yaml
-   id: ping
    execute-command: /var/scripts/ping.sh
    command-working-directory: ./
    response-message: pong
-   id: addition
    execute-command: /var/scripts/addition.sh
    command-working-directory: ./
    response-message: I got the payload!
    pass-arguments-to-command:
        - source: payload
          name: numberA
        - source: payload
          name: numberB
-   id: view
    execute-command: /var/scripts/view.sh
    command-working-directory: ./
    response-message: triggered
-   id: create
    execute-command: /var/scripts/create.sh
    command-working-directory: ./
    response-message: let see
-   id: something
    execute-command: /var/scripts/create.sh
    command-working-directory: ./
    response-message: let see
/etc/webhook #

And the log of the webhook:
[webhook] 2020/09/15 18:13:58 version 2.7.0 starting
[webhook] 2020/09/15 18:13:58 setting up os signal watcher
[webhook] 2020/09/15 18:13:58 attempting to load hooks from /etc/webhook/hooks.yaml
[webhook] 2020/09/15 18:13:58 os signal watcher ready
[webhook] 2020/09/15 18:13:58 found 1 hook(s) in file
[webhook] 2020/09/15 18:13:58 	loaded: ping
[webhook] 2020/09/15 18:13:58 setting up file watcher for /etc/webhook/hooks.yaml
[webhook] 2020/09/15 18:13:58 serving hooks on http://<IP_ADDRESS>:9000/hooks/{id}
[webhook] 2020/09/15 18:14:38 caught HUP signal
[webhook] 2020/09/15 18:14:38 attempting to reload hooks from /etc/webhook/hooks.yaml
[webhook] 2020/09/15 18:14:38 found 5 hook(s) in file
[webhook] 2020/09/15 18:14:38 	loaded: ping
[webhook] 2020/09/15 18:14:38 	loaded: addition
[webhook] 2020/09/15 18:14:38 	loaded: view
[webhook] 2020/09/15 18:14:38 	loaded: create
[webhook] 2020/09/15 18:14:38 	loaded: something
[webhook] 2020/09/15 18:15:28 [7eb3ca] incoming HTTP POST request from <IP_ADDRESS>:37090
[webhook] 2020/09/15 18:15:28 [7eb3ca] ping got matched
[webhook] 2020/09/15 18:15:28 [7eb3ca] ping hook triggered successfully
> [7eb3ca] POST /hooks/ping
> [7eb3ca] Accept: */*
> [7eb3ca] Accept-Encoding: gzip, deflate, br
> [7eb3ca] Connection: keep-alive
> [7eb3ca] Content-Length: 6
> [7eb3ca] Content-Type: application/json
> [7eb3ca] User-Agent: PostmanRuntime/7.26.5
> [7eb3ca] id:
> [7eb3ca] {
> [7eb3ca]
> [7eb3ca] }
< [7eb3ca]
< [7eb3ca] pong
[webhook] 2020/09/15 18:15:28 [7eb3ca] 200 | 4 B | 230.806µs | localhost:9000 | POST /hooks/ping
[webhook] 2020/09/15 18:15:28 [7eb3ca] error locating command "/var/scripts/ping.sh": exec: "/var/scripts/ping.sh": permission denied

Well indeed, it seems it something related with the permissions on the files itself, that's why it can execute it! Smart move @moorereason

Here our fix!
 kubectl exec podname -- chmod 777 -R /var/scripts

I know I know, the chmod 777 is extreme but it's a quick fix for now and maybe someone else with have a better idea!
But hey, it's working!

I'm closing the issue because it's fixed now 😄
Hope it will help someone else!
Thanks you a looooooot @moorereason  !!!

If someone want the permission to be done inside the container with a cron job
FROM joemiller/go-init-sentinel as go-init-sentinel

from almir/webhook as webhook
COPY --from=go-init-sentinel /go-init-sentinel /go-init-sentinel
EXPOSE 9000

RUN apk update && apk add --no-cache curl

COPY ./scripts /var/scripts
COPY ./hooks.yaml /etc/webhook

COPY ./cron.sh /etc/webhook

# Use crond -l 2 -f to debug inside the pod
# Use crontab -l

# If you want every x seconds INSIDE change the code
RUN echo '*  *  *  *  *    /etc/webhook/cron.sh' > /etc/crontabs/root

ENTRYPOINT [ "/go-init-sentinel", "-watch=/etc/webhook/hooks.yaml:SIGHUP", "-watch=/var/scripts/:SIGHUP", "--"]

# Default command
CMD crond -l 2 -b && webhook -verbose -debug -hooks=/etc/webhook/hooks.yaml -hotreload

cron.sh
#!/bin/sh

echo "/var/scripts start"

REMAIN=60
INC=5
while [ $REMAIN -gt 0 ]
do
    /bin/cmd -arg1
    sleep $INC
    # echo "ok $REMAIN"
    chmod 777 -R /var/scripts
    REMAIN=$(($REMAIN - $INC))
done

sleep 1
echo "end"
sleep 1

echo "/var/scripts done"

./scripts/ping.sh
#!/bin/sh

echo "pong"

./hooks.yaml
#   this is an empty hook
#   have to be replace dynamically
-   id: ping
    execute-command: /var/scripts/ping.sh
    command-working-directory: ./
    response-message: pong

With all of those files and basic configuration, the cron job will need 1 min after the launch of the container... an after that every 5 seconds the permission is given to the files.
So just execute a command to copy files at /var/scripts and then wait 5 secs, and it should be ok! Have fun!


First cut of a Front SDK for JavaScript

It has definitions for the following sections of the Front API:

Inboxes
Conversations
Messages
Comments

It uses the same snakecase for property names as the API itself.
See the README for a brief overview.
Brief testsuite for current functionality included.
Change-Type: minor

Due to Front's 'one API key does everything' approach, testing currently requires private keys not released with this repo. These keys are expected to reside in a suitably secure CI builder once discussed. They are currently:

apiKey - The Front API key
testInbox - The name of the Inbox to test against
testChannel - The ID of the channel to test against
testAuthor - The username of a user to test with

@Page- Ping! :)


false "no tp" warnings

certain actions count as a tp, for example getting out of a boat/minecart. These should be allowed and shouldn't give the player a warning if they're carrying the treasure.

how could we test for that

how could we test for that

Events probably have a source attribute, but if not then I'm really not sure.


Added note about preferring HTML over PDFs

Fixes #130

Hey there! Anything I can do to help get this merged?

@loganfranken the branch cannot be merged due to a conflict.
Also I would like to see some expanded info an why not to use PDF. Personally I would expend it to explain how a PDF or any non-native format like a word processor document required external readers and break the flow of navigating the site.

Updated! Thanks @garster!

@loganfranken, Wonderful. And thank you for not saying PDF Format (Portable Document Format Format)


Support multiple port bindings

Use Java RX to support multiple port bindings in MockServer and Proxy so that the MockServer can be bound on multiple ports with a single thread pool.

still needs tests coverage on:

PortBinding serialisation and deserialisation
handler methods for Netty and War
integration test on port binding rest API

This has been completed.


Extracting images line temporarily appears twice during conversion.

During conversion, the "Extracting:" line appears twice until the "Converting Images" process has completed - at which point the second "Extracting:" line disappears.
Note that the second "Extracting:" line never seems to get to 100%.

This is resolved


crash once enter all data

hello, I've downloaded everything and all working well, one I fill the date, location to save, download channel, and channel address the window crash

Hello,
Thank you for reaching out and for trying out the project. It's great to hear that everything is working well for you with one small issue. It appears that you're experiencing a crash when filling in the date, location to save, download channel, and channel address.
The issue you're facing might be due to the missing pytube library, as you mentioned. To resolve this, you can indeed try running the following command:
pip install pytube

Downlaod Executable File YotubeDowloadManagerV2

Hello, many thanks for your reply, I installed the missing pip install pytube
But now I’m getting this
“[INPUT] Enter your choice! » 2
Download From a PlayList -
[INPUT] Enter a Playlist URL! » https://www.youtube.com/watch?v=rYEDA3JcQqw&list=PL6aXn5OcbJVUc0x0tUojhcrRf80hScGai
Total Videos 8
Download PlayList Bulk or Selective -
[01] » Downlaod all Videos From Playlist
[02] » Downlaod Recently Uploaded Videos From Playlist
[INPUT] Enter your choice! » 1
Traceback (most recent call last):
File "pytube_main_.py", line 341, in title
KeyError: 'videoDetails'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 77, in
File "pytube_main_.py", line 346, in title
pytube.exceptions.PytubeError: Exception while accessing title of https://youtube.com/watch?v=rYEDA3JcQqw. Please file a bug report at https://github.com/pytube/pytube
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 80, in
NameError: name 'VideoUnavailable' is not defined
[7952] Failed to execute script 'main' due to unhandled exception!”
From: Xavier @.>
Sent: Thursday, November 2, 2023 8:10 PM
To: XavierisOP/YouTube-video-downloader-with-Python @.>
Cc: nf24eg @.>; Author @.>
Subject: Re: [XavierisOP/YouTube-video-downloader-with-Python] crash once enter all data (Issue #1)
Reopened #1https://github.com/XavierisOP/YouTube-video-downloader-with-Python/issues/1.
—
Reply to this email directly, view it on GitHubhttps://github.com/XavierisOP/YouTube-video-downloader-with-Python/issues/1#event-10846849151, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AO7IOZIERMHOL2K32DRUZXTYCPHVVAVCNFSM6AAAAAA6D2CJ4KVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJQHA2DMOBUHEYTKMI.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

I updated all the pip but I'm getting this error  (the link to youtube is just for test)
Enter a Directiory where all video will be download! » C:\Users\XXX\youtube
CHOOSE THE OPTION ACCORDING TO YOUR NEED -
[01] » Downlaod a Single Video
[02] » Download From PlayList
[03] » Download From a Channel
[INPUT] Enter your choice! » 01
Download for a Single Video -
[INPUT] Enter a video URL! » https://www.youtube.com/watch?v=XsVtSPgaRzI
Traceback (most recent call last):
File "pytube_main_.py", line 341, in title
KeyError: 'videoDetails'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "main.py", line 45, in
File "pytube_main_.py", line 346, in title
pytube.exceptions.PytubeError: Exception while accessing title of https://youtube.com/watch?v=XsVtSPgaRzI. Please file a bug report at https://github.com/pytube/pytube
[14056] Failed to execute script 'main' due to unhandled exception!

I wanted to provide a quick update on our program.
Currently, I'm occupied with other commitments, and I've made essential fixes.
Check it out New release......


[Feature Request]: Warn users of pod restart when editing workbench

Feature description
When editing a workbench most changes require the pod to be restarted if it is currently running.  Before saving the changes a warning should appear stating that the pod will need to be restarted and users should save any notebook data before proceeding.
Restarting the pod without warning could result in loss of user data that has not been saved or pushed to git.
Describe alternatives you've considered
Instead of automatically restarting the pod or giving a warning, you could add an extra step after the changes have been saved.   A message could be displayed on the workbench item indicating that the changes will be applied once the pod has been restarted with a button to "Restart Now".
Anything else?
No response

We're going to need to work with UX to make sure we cover these scenarios in a way that is consistent.
cc @kywalker-rh we should talk to make sure we make a sane one-effort solution to this problem from all the angles that a user can cause this to happen.
The restart is done by the notebook-controller (and outside of our control as far as I know -- I'll investigate to see if there is an annotation or something we can use to avoid auto restarts), so we need to prompt them before making changes that what we are about to do will potentially cause a loss of data.

Talked with Kyle, we will go with a Blue (info) Alert at the bottom of modals/pages as needed to any operation that will restart the Workbench.


[BUG]

ElasticDump version - 6.82.3
Elasticsearch version - 7.17.8 (Elastic cloud)
Node.js version (note that nodejs v10+ is required for this tool) - 17.9.0

Describe the bug
We have build a java framework around the elasticdump utility to transfer records based on some search queries on timestamps. The java process runs every 15 mins and transfers the delta data to the backup cluster. We are using the java process builder to run the elasticdump commands with a search body to selectively transfer the data. After java process is created it waits for the elasticdump response. This is working as expected, but from time to time we find the java process to await indefinitely waiting on the elasticdump command to complete.
To rule out any issues with the java process we did try manually running the same elasticdump commands several time and we have seen from the outputs generated by elasticdump that process just stops without doing any more data transfer.
Below is the logs of one such instance where we can see the data transfer has stopped without completing or erroring out.

no logs after this...
Is there something that can be done to figure out the problem?
Below is the command we are using to transfer the data for one of the indices
elasticdump --input=${SEC_PROTOCOL}://${SEC_USERNAME}:${SEC_PASSWORD}@${SEC_HOST}:${SEC_PORT}/segment-20231008 --output=${PRI_PROTOCOL}://${PRI_USERNAME}:${PRI_PASSWORD}@${PRI_HOST}:${PRI_PORT} --type=data --limit=1000 --searchBody="{"query":{"bool":{"must":[{"query_string":{"default_field":"","query":"<field_value>"}}]}}}"

The issue could be the size of the file. When you're dumping large amount of data it might cause issues for some system since you're writing a buffer to a very large file, i.e. the OS might not be able to keep up.
I would recommend trying to use --fileSize just to see if this helps your situation.

Try using the --debug and see if that helps. Also take a look at --retryAttempts., this is 0 by default, can be used in combination with --retryDelay (default: 5000 milliseconds).
Sometimes elasticsearch or the network may drop connection. Retrying just to see if it helps

with --debug enabled we didn't get much insight.. it was additionally logging the scroll id but at the end it just stopped like earlier.
with retryAttempts flag set it will only retry on failures, right?
Because the problem here is it doesn't fails gracefully to get a handle. It just stops the data transfer. Ideally the process should exit with or without failures.
On the node side, can we add some properties to log more info like uncaught exceptions, etc?

I'll add a flag to check for uncaught exceptions.

https://github.com/elasticsearch-dump/elasticsearch-dump/blob/master/bin/elasticdump#L151-L160
@L151 you can add the following to your installation and test
process
  .on('unhandledRejection', (reason, p) => {
    console.error(reason, 'Unhandled Rejection at Promise', p);
  })
  .on('uncaughtException', err => {
    console.error(err, 'Uncaught Exception thrown');
    process.exit(1);
  });

since we are creating a image with the java framework, we just install the elasticdump package.. so changing the executable is not feasible for us.
Will it be possible to create a build with the changes.. Thanks

Yea sure.

added to https://github.com/elasticsearch-dump/elasticsearch-dump/releases/tag/v6.104.2


String enum record can't accessed by declared index.

TypeScript Version:  2.4.2
Code
Run following code with --noImplicitAny option.
// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.
enum HTTPError {
  CLIENT_ERROR = 'CLIENT_ERROR',
  SERVER_ERROR = 'SERVER_ERROR',
  UNKNOWN_ERROR = 'UNKNOWN_ERROR',
}

// Example 1
type RequestErrorsMap = Readonly<Record<HTTPError, string>>;
const requestErrorsMap: RequestErrorsMap = {
  CLIENT_ERROR: 'Client has problem.',
  SERVER_ERROR: 'Server has problem.',
  UNKNOWN_ERROR: 'Unknown problem occurs.',
};

declare const index: HTTPError;

requestErrorsMap[index]; // Example 1.1
requestErrorsMap[index as 'CLIENT_ERROR' | 'SERVER_ERROR' | 'UNKNOWN_ERROR']; // Example1.2

// Example 2
type EM = {
  [K in HTTPError]: string;
};
const em: EM = {
  CLIENT_ERROR: 'Client has problem.',
  SERVER_ERROR: 'Server has problem.',
  UNKNOWN_ERROR: 'Unknown problem occurs.',
};

declare const i: HTTPError;

em[i]; // Example 2.1
em[i as 'CLIENT_ERROR' | 'SERVER_ERROR' | 'UNKNOWN_ERROR']; // Example2.2

Expected behavior:
example 1.1, 1.2, 2.1 and 2.2 pass type check
Actual behavior:
only 1.2 and 2.2 pass type check
This makes an issue when dealing with js libraries. (whose type is from lib def file)

looks like a duplicate of 17288


Feature/rebind report to dataset

@alex-davies Any chance getting this merged? The retry logic and the rebind feature is something we could really need in the project Im currently working on :D


Add Intercom

This change addresses the need by:

Adding the supplied markup to the pages layout so it gets appended to
all pages

you'll need to do this on https://github.com/subvisual/blog.subvisual.co and https://github.com/subvisual/apprenticeship.subvisual.co as well

On it

couldn't this be inside the manifest with the rest of the JS code? I moved some stuff there recently precisely to avoid the extra HTTP request that this will cost us

@naps62 in this case maybe we can benefit from the fact that this file can stay cached forever instead of merging with the existing JS.

@gabrielpoca What do you mean by forever? And are you talking about browser cache?

I mean that the file will never change, when our js will, the browser can cache it longer, and maybe we can even use service works or appcache to keep it forever.

My browser cache last about 5 days, let's say that the average user has a cache of 15 days, in practice that means that he'll probably never have files from our site cached, and if he does, it's as likely that he has application.js as it is for intercom.js.
Appcache is a possibility, but I don't think this amount of code justifies that. If we can get everything in one http call, that should be fast enough. We can test it though, with and without app cache.
@naps62 One thing we have never used is an reverse proxy such as varnish, would that improve the load times substancially?

@gabrielpoca Actually after some research I found that appcache has been deprecated in favor of service workers, which are not supported at all in IE or Safari.
Also, if I'm not mistaken you need even more JS just to make that work, so not really a good option I would say, but not very familiar with it I have to say.

@zamith it was just an idea, I said service works or appcache, or maybe a combination of both. I'm eager to see service workers in action, but I guess it's not the best place.

I would go with having it on the manifest, as the scripts are not updated with a regularity that justifies it (4 commits in 6 months.
Here's my reasons for having done it like so:

The fact that Intercom provided this code as two separate <script> tags leads me into thinking they have dealt with some sync issue in the past and want to prevent some race condition;
Intercom is an addon to the site, so it makes more sense to load it after all scripts required by these pages have been loaded, which means this would have to be done after yield_content :javascripts
I wasn't able to have Intercom run successfully in development (also didn't dig into the rabbit hole tbh), which took the confidence to try and challenge the way they prepared this code.

Now, if you guys these don't have a meaningful impact, then I'd rather have it in the manifest file and merge the Intercom configuration in the same <script> tag as Typekit.

I was just following the same rationale that I applied here: https://github.com/subvisual/subvisual.co/pull/114
We might be fine either way, but since we already moved other external services to the manifest, I'd say it's better to keep things consistent.
Assuming the file can stay cached forever is a mistake, not only because of what zamith said, but because of what's stated in this post, section "HTTP Caching"

@zamith as for varnish (or a similar tool), it's still something I have on my backlog titled "DevOps things to try out when I have the time"

@pfac Also, having two separate script tags is probably irrelevant. They probably set it up like that so that you can use a CDN for the main script

I was thinking about this and I believe we should load intercom asynchronously. It will not change the page weight. It will make an extra request, but in the other hand the JS that is crucial to the site will be available faster.

@gabrielpoca I wouldn't say it is crucial. I'd rather people can see the page faster and intercom appear later, than having them wait for it. It is important for us to have intercom there, but it is not crucial that it is there at the time of rendering.

@zamith apart from that, I didn't understand if you agree with my idea or not.

@gabrielpoca What I'm saying is that I don't really care when it is loaded, it can be 1s or 2s after the page being rendered, as long as it has no impact on the rendering time.

@zamith but it does affect. Because our JS is necessary for things like the Nav to work.

@gabrielpoca Ok, then why not have a defer for intercom?

@zamith I don't understand. I suggested loading is asynchronously, aren't you talking about the same thing?

@gabrielpoca As far as I understand it, async will stop render to execute the script whenever it is ready, and defer only executes it after render, which is more in sync with what I was saying. Is this not true?

I guess, I don't know, I didn't suggest async or defer, I simply suggested asynchronously. If that information is correct, then defer makes more sense.

Oh, I thought I had read async, my bad. Yes, I think defer is the way to go.

Again, quoting from this same post:

It's far better to use async and defer attributes on your script tags

to clarify, he states that we should use both. And he talks about this in precisely the context of loading 3rd party integrations

Then I guess we all agree on what to do :tada:

I'm good with that, but I'd like to understand why you would use both. I don't think he explains it in that post. :/

I think this is it:

The defer attribute may be specified even if the async attribute is specified, to cause legacy Web browsers that only support defer (and not async) to fall back to the defer behaviour instead of the blocking behaviour that is the default.

found here.

\o/ nice! Will change Intercom to the vendor dir and load it with both defer and async.

Changed

:tada: